>>8
Concepts and axioms would've been glorious benefits, but they've been remanded to a technical report. They were also integral in reducing the complexity of C++ for beginners that weren't writing them, though admittedly, "spectacularly bad" error messages are only a part of the story. The rest is semantic overload and the lambda syntax illustrates precisely what is the largest percentage of its badness: Its complex syntax.
There is an entire working group dedicated to figuring out how to parse additional C++ syntax. No mortal can keep all the rules in their head. Nearly every single thing they change introduces new keywords, syntax, or semantics.
In this vein, the right angle brackets and new
enum semantics are probably the most potent.
auto is a necessary addition. The uniform initialization syntax change was good. From a syntax perspective, there was very little else that helped.
As far as utility, other than the above mentioned, lambdas are something that were sorely needed. Closures are simply too useful to not exist where abstraction is important.
nullptr closes a huge gap in the type system. For example, because
std::string has an implicit conversion from
unsigned char *, you can actually use 0 in comparisons with std::string. Not to mention the overloaded function resolution when you're using null pointers... they default to the integer versions. It's subtle things like this that lead to confused noobs and very long debug times.
rvalue references are good from a performance and library perspective. Respectable additions. Actually, most of the standard library changes are great.
Those inheritance type specifiers should've been upgraded to necessary or at least had one of the labels be the default. The syntax makes it horrible and ugly to use and those are extremely useful for limiting inheritance and increasing clarity.
Variadric templates are pretty useful, I guess. Type-safe printf has been a long time coming. I wouldn't personally use them, but recognize the power in such an option.
Memory model changes were necessary. User-defined literals are retarded.
Overall, it's better to have it than not, but it still doesn't address the primary problem with Sepples because anything that adds to Sepples doesn't address it. It does, however, increase Sepples' power for writing libraries and general programming constructs. This is what Sepples is good at. So pick your poison, I suppose.