[Silhouette]

Of course - the Google Style Guide being a prime example.

Indeed, though it's been going on since long before Google was around!

Have you looked at the source for (say) your Standard Library implementation? If you are not intimately familiar with it (which kind of negates the advantages of using a library in the first place) you won't stand a chance of debugging it, no matter how deep your knowledge of the C++ Standard.

Some years ago, I did exactly that. Found a bug in it, too.

Part of my concern with the ever-increasing complexity of C++ since C++11 is that what I did back then would be increasingly difficult today, because there are so many intricacies aimed at library writers squeezing out every last drop of performance. Of course, for a systems programming language like C++, that emphasis is understandable. But as I said, extra complexity in language design always comes at a cost. And if we'd had to wait for someone upstream to fix the bug in the library I mentioned above, that cost would have had quite a lot of digits in it and a dollar sign at the front.

[steerablesafe]

Many of the new features will help with readability. Conditionally explicit is a good example. There are a ton of places in the standard library where conditionally explicit constructors are needed, and the workaround isn't too nice, it's a ton of boilerplate.

Concepts will also help for the same reason. SFINAE is used a lot in libraries and it's simply not readable. Concepts will make it more approachable.

[Silhouette]

Many of the new features will help with readability.

Indeed, and this has been the argument for many of the new developments right back to C++11. There is something of a devil-you-know argument here as well, though.

SFINAE is a surprisingly useful consequence of the way overload resolution is specified, but as you say, it's been used a lot. Many C++ programmers have encountered it over the years. Much has been written about it to explain it for those encountering it for the first time.

Realistically, C++ programmers will still have to understand the resolution rules even after C++20 becomes widely adopted. Those rules are also relevant for other reasons, and even in the specific case of SFINAE, the entire ecosystem isn't going to rewrite all its code to use newer alternatives overnight.

So now, any new C++ programmer who wants to analyse a third party library to trace the source of a bug is going to need to recognise multiple techniques to achieve that kind of behaviour and not just the strange but at least ubiquitous way we had before.

[bluGill]

Only somewhat. As new features become more common the old ones that were harder to use become less important. C++11 has made a big impact on the type of C++ you see in the real world, now that it is 9 years old we can see change. The change wasn't overnight, but it is there.