Sure you can, by introducing language features that make it easier to achive the same while being less error prone.

For example, in template metaprogramming we can get rid of tag dispatch and SFINAE thanks to static asserts, constexpr and if constexpr.

Likewise you might decide to shot your code with C style arrays, or use the STL data types with bounds checking enabled instead.

I hope that at some point C++ programming can have a solid "good parts" style guide, akin to Crockford's JavaScript book.

I feel a lot of that probably isn't conventionally achievable since C++ covers a lot of situations with different needs, but if 20% of the functionality could cover 80% of the needs at some point I think it'd be great for the language.

Stroutrup's "Tour of C++" might be what you're looking for.

Like C++ Core Guidelines? https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

static asserts do not replace tag dispatch and SFINAE as they don't affect the overload set, the instantiation has already happened at that point. However, concepts will do this in, probably, c++20. For now, is_detected is like a concepts lite that allows for a big simplification.

One thing to remember though is that there are two things at play here. The library writers tools, like TMP, and the users. The users can do a lot and never worry about SFINAE/tag dispatch. The library writers use it to allow the users of the library to have a potentially very simple experience.

Also, Greenfield C++ can be way different than pre 2011 C++. The cost of things that people would work around has gone way done to zero in some cases. Like returning a value from a function is like constructing it in place at the caller. So that takes away a need to use the heap to allocate it or to copy it when you return it.

I should say, I mean the overload has already been found at that point.

Thanks for the correction, I was simplifying, without going into enable_if details and such.

enable_if is ugly. But a lot of the extra ugliness is people putting everything into the condition and not abstracting the parts of it into other traits. Just like looking at long functions.

Disagree. In the sense that the code one writes gets simpler. Range based for loop alone does a lot. Auto destructuring of tuples, initialization lists, std::variant... etc. all do their part in making new code less verbose and less bureaucratic. It's just sugaring but it's at least a standard sugaring.

While I agree that C++ has improved a lot, and while all these extensions to the standard library can, when used carefully, considerably increase readability... well, there remains the fact that they still need to be used with extreme care.

See https://github.com/isocpp/CppCoreGuidelines/issues/1038 for an example of what I'm talking about.

So, readability increases, but the mental load of making sure that stuff doesn't break in subtle and non-euclidian ways keeps increasing, at least when refactoring existing codebases.

Yeah, memory handling is still challenging to handle correctly - in the sense it need forethought and constantly remembering what one can and can't do (list iterators good long term references, vector iterators bad long term references, etc). string_view is a good example of a situation where garbage collector would save a lot of headache.

Also, small functions are generally free to call and are often inlined. So you can keep your function simple and at a consistent abstraction level without paying for it. Do this until proven otherwise, with real perf data. I find a lot of people are afraid of this or they say that they don't know what is going on. I suspect some may also prefer writing in asm and not using abstractions to tell the story.

The code one writes does get simpler. Unfortunately, the code some dozen developers write ends up with all imaginable ways of writing the same thing. That's my biggest pain with C++.

"the code some dozen developers write ends up with all imaginable ways of writing the same thing."

I do know what you mean. But that's not really the languages problem but of the coding guidelines and using code review to maintain legibility.

I don't know. I don't have the same problem with Lua and Python. Lua is simply small enough not to have baggage and Python seems to have a healthy community that keeps updated with best practices. It also helps that both languages are designed to be readable. C is also simple enough, as long as code doesn't abuse pointers.

The simplicity isn't in the language. It's in the programme written with it. That's where it's needed and that's where it counts.

But I seem to remember watching a talk by Kate Gregory in the last few weeks where her main point is that you really need to have a full understanding of the language to program in it. So if C++ has baroque complexity that is shunned by best practices you still need to be aware of it. I know the C++ folks would like to escape their past but there just isn't a good way to do that, short of a clean break with backwards compatibility.

I bet they could actually pull off a break with old code if they would release tools, ala Abseil, which took care of migration for you. I think it's reasonable to accept that legacy code needs to be freshened up every so often to allow the language to evolve. We have Google translate for human languages, why don't we have it for code? It seems like a far easier task.

You can't make C++ simpler but you can make some C++ simpler, as in the programs written in it. C++, the language, is too old and too widely used to be made simple.

This was actually the topic of Herb Sutter's talk[1].

Things like meta-classes will drastically simplify end-user code.