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.
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.
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...
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.
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.
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.