FWIW, I can’t ever remember a time when the most widely used compilers in practice weren’t around 5-10 years behind changes in the standard. Part of the issue is that adoption takes time, and always will. A lot of people using C++ professionally don’t want to be on the bleeding edge of language changes. Some do, but a lot don’t, for good reasons.

When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.

Yes, it changed my point of view that it is about time WG21 goes back to the old ways of only standardising existing practice, or at very least proposals without preview implementations shouldn't even get discussed in first place.

The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only.

And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.

It is worth noting that one of the main reasons why C++ standard evolution is faster nowadays is because the "bare minimum" for consideration of acceptance in the standard is working examples on a fully functioned compiler. This tends to make it a lot easier for other compilers to implement those features as there is at minimum a working reference to compare against (vs older still unimplemented features like modules where nobody really ironed out how to properly implement them until after they were shoehorned into the standard)

Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.

Yeah, I've been very worried about this. C++23 is basically unimplemented as far as I'm concerned. Working on C++26 makes no sense to me. They gotta space it out more than 3 years, if nothing else.

I cannot believe how, after all these years, we don't even have `restrict` in the language, nor uniform function call syntax (i.e. x.foo(y) being interchangeable with foo(x, y) ); but we do get the ultimate bells-and-whistles in the form of reflection and reflection-based code generation; and the half-baked coroutines mechanism.

uniform function call syntax and a `restrict` mechanism have not made it in to the standard after so many years

That is more on the fact that less investment is made in C++ compilers nowadays. Companies are migrating away from C++ and it shows in compiler development.

the only people that complain about this don't actually write C++