As of today, C++17 is the latest one can aspire to use for portable code, and better not making use of parallel STL features.
Naturally when code portability doesn't matter, it is another thing.
All my C++ side projects are written against C++latest on Visual C++, and make full use of modules and concepts.
* std::span is in! https://stackoverflow.com/q/45723819/1593077
* Designated initializers (like in C99)
* Spaceship operator and default comparison ops
* More language constructs can be constexpr'ed
* Better structured binding
* using on enums
* Don't need to say "typename" as much :-)
* Bunch of minor improvements to the standard library
Note I did not say coroutines. I still don't understand how that boondoggle made it into the language the way that it has.
As for the rest, the point stands regarding portable code across various C++ compilers.
I agree on the co-routines, while I know C# co-routines relatively well, and the C++/CX stuff that was used as inspiration for Microsoft's initial proposal, they are a bit of a mess, when key WG21 members also don't fully grasp how they have to be implemented, and we need two hour sessions on C++ conferences to go through "hello world" kind of implementations.
It's not a trap if you weren't expecting bounds checking.
> we need two hour sessions on C++ conferences to go through "hello world" kind of implementations.
After one hour it became clear to me I am going to stay away from that stuff until either it becomes much more usable (unlikely TBH) or someone forces me to use it...
I suppose C++26 brings std::span::at, although exceptions are a different can of worms.
Pre-C++98 compiler frameworks used bounds checking by default.
And yes, if I am calling the shots, bounds checking are enabled in release builds.
Never has been a problem other than performance cargo cult folks.
Thankfully governments are making this less of discussion.
No disagreement there. But I'd prefer to turn it on across the board via compiler flag rather than pull in a special library for it and remember to use that library consistently. And if that's the case, I don't see std::span as any more problematic on this front than the rest of the standard library.
(Yes, I know, GSL isn't really a special library on Windows. But anywhere else, it is.)
Which compilers? I'd bet there are compilers that are still stuck at c++98.
The point is, obviously, use other features introduced in C++20 and not have to deal with artificial restrictions when you opt to onboard onto whatever feature you'd like.
To me C++20 has more to do with designated initializers than modules, for the very obvious reasons. It's fine if you take a pass at an upgrade and prefer to take the hit of migrating through a bigger delta, but framing this thing as "what is the point" is indeed missing the whole point.
However I do agree with the feeling for large scale adoption.
The way modules and concepts went down, or the way GC API got added only to be removed, or ongoing contracts discussion, has pretty much settled my opinion that WG21 really needs to adopt the same approach as other programming language communities.
Papers without working implementations for community feedback shouldn't be accepted at all.
I think that everyone has misguided and naive expectations on how such a radical change would roll out to production software.
Changing dpendency management and updating build systems is a hard sell for professional projects delivering production software. It's the most radical change in how you're software is built with zero upside in terms of features. Best case scenario your software works as it always did. Worst case scenario you wasted tons of developement effort to retool and revamp your whole CICD pipeline just to break your project. Hard sell. I mean, why do people think so many projects are still stuck with C++11?
Drastically reduced compilation time is a huge upside for modules.
You can achieve those already with the adoption of basic architecture principles and the incorporation of tools like compiler caches such as ccache. Those who have an interest in those already do it. Modules are no silver bullet and change nothing.
Apple and Google kept using clang header modules, switched focus to their C++ replacements, and clang transition to C++20 modules languished until a few heroes stepped in to do the work.
Meanwhile GCC is still work in progress.
And build tools are still a mess, even cmake doesn't have yet a story for header units.
As for Microsoft, except for Office, there isn't a single Microsoft product, especially C++ SDKs, that make use of modules in any form.
This is quite different from how other programming language ecosystems migrate features from preview into stable.
Currently the Standard is at C++23 and we are ~4 years behind (C++20 is not portable, as you say). At this rate, by the time we get to C++40 or 50, compilers could be behind to a comical degree, like 15 years.
Personally I am interested to see how many unimplemented features it takes before the Committee takes action. (I would find it superbly amusing if they simply did nothing and we got to a point where no new C++ features ever became available.)
It will be good enough for the industry use cases where C++ matters, while other languages keep slowly eroding C++'s market share.
Example of such scenario, LLVM, GCC, JVM, V8, CLR are all currently settled on C++17, maybe eventually C++20, they don't need any additional features, for their C++ use cases, other than having GCC and clang keep up with ISO.
How many people care about COBOL or Fortran 2023 standards?
One notable exception is that I did a project with C++20's coroutines recently.