I'd be curiously to see how many people actually use modern C++ professionally. I've always been under the impression that adoption of the standard lags behind by like 7 years or so.
It wasn’t my call, though. Meta has a relatively big C++ infra team that participates in the standards committee, maintains the Folly utility library, and decides how complex new features like coroutines are adopted. On top of that, my code plugged into another team’s system, and they had written their own guidelines on how/if they want to use specific C++ and Folly features.
These guardrails were really useful for a C fossil like me with an on-off relationship to C++… It’s not a terrible language anymore, but it’s even harder than before to find the right subset. At least boost can be finally buried.
The fact that TensorFlow on Python can use GPUs/TPUs is a no-brainer, but that only works in the server center and not in the field.
Depending on where you work at, my experience suggests 2-5 years for adoption.
No plans to go back to an older standard.
Given the quality and extent of c++20 support over the past few years it can’t have meant using a lot of c++20 at least for most of the time. Then again things like fmt and ranges had 3P libraries that influenced the standard (I’ve been using them myself for years) so more is possible than came with the compilers.
All that being said I would rate the comment as hyperbole. Had it been phrased something like “I’ve been compiling specifying c++20, and have heavily leant on 17 and some key 20 features” I’d be quite fine with it.
Features like coroutines still require a lot of plumbing in order to use; features like that go into a standard so that version n+1 can have the right user abstractions, which can only be developed through experience.
TBH I quite enjoy using C++ from the perspective of a language not based on C (at least don’t think of it that way) with an amazing c-compatibility layer only very occasionally needed. For example I worked on a large system compiled with c++17 at a very high level of abstraction, but that had a deep grotty memory management using pointers, malloc and mmap implemented in two files. It was invisible to the people worrying about the high level logic.
[1] https://discourse.llvm.org/t/important-new-toolchain-require...
Anyways, I don't know what you are calling "modern" C++, but for me it is C++11 and up. C++11 to C++20 introduced a few major changes but none as pervasive as C++98 to C++11.
Even at W3C you were expected (when I had anything to do with it) to actually build the prototype before you publish the standard, and obviously the IETF's "Rough Consensus and Running Code" speaks to that way of thinking too.
I feel like if ISO 216 claimed you can fold a square 1x1 metre piece of paper in half and preserve the proportions, that wouldn't have survived into a published document. Sure you can write that claim, but you cannot actually make that fold, it's surely amazing that the C++ Committee are not subject to the same consideration and yet here we are.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n361...
What the paper says is that static if would make it much harder to perform static analysis of source code, not really because it's hard to implement but because the kind of combinatorial explosion introduced by having non-local bifurcating source code branches to analyze makes analysis incredibly slow.
C++ did eventually adopt if constexpr, which does not have this problem since the branches are always local.
clang is trailing C++20, since Apple and Google stop caring to be first line contributors.
GCC is actually not that far behind VC++.
And regarding building prototypes, VC++ modules implementation was the prototype.
I don’t think they do this much if at all any more having been burned in the past. If anything they are more extreme in the other direction: for every person who complains the standard is moving too quickly there is someone complaining that the committee is moving too slowly (“what? Still no networking?”)
They aren’t as hardcore as the IETF’s two independent implementations but I’m not sure how faithful the IETF ever was to that (perhaps apocryphal) criterion anyway.
But many companies do not like how the standard library does memory management and they roll their own allocators and libraries that use them.
But one of the nice things about c++ is when you have specialized needs you can write your own implementation of something and it’s just as “first class” as something in std::.