they do address real problems - specifically those of people trying to write very efficient libraries. if you are not in that group, simply don't use those features.
Sadly, the C++ standard bodies are actually breaking old code in new versions of the language.
For example, C++/11 introduced UTF8 string literals. Great feature which does what you’d expect – declare a string literal in source code, get a const pointer to null-terminated array of utf-8 bytes.
Then a decade later, in C++/20 they refactored these UTF8 literals to evaluate into const pointers to the new incompatible data type, char8_t.
It’s so bad that compiler developers had to implement switches to disable the new BS. Unfortunately, these switches are incompatible across compilers, -fno-char8_t in gcc, /Zc:char8_t- in msvc.
They address the problems of people that care enough to show at WG21 meetings, endure the multiple rewrites of their papers, and gather as many votes as they can.
As simple as that.
Many of the modern features aren't even exposed to the comunity as preview features before being voted into the standard.
And yet they can't update the standard library types to not be slow as hell because of ABI concerns.
If C++ was really all about speed then we'd have destructive move letting you pass unique_ptr in a register without compiler trickery. The fundamental number one constraint on new C++ behaviors is ABI compatibility. The rest is secondary.
The c++ standard absolutely cares deeply about abi compatibility. The committee can't even update intmax_t because it is an abi break. "Code compiled today and linked against code compiled years and years ago must behave correctly" is an absolutely premier design constraint when it comes to papers and it has prevented oodles of low hanging performance opportunities.
It's not in the standard itself, because the standard doesn't directly talk about ABI. But there was a vote within the committee not to break ABI, as you can see in the Prague 2020 meeting here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n48... (scroll down to page 11). And if you ever listen into any committee meetings or try to present papers, ABI breaks are very serious concerns that can torpedo proposals.
Not only that many of the Carbon devs are former clang contributors, and one reason that clang is now on third place regarding ISO support, is that other devs had to step into what was previously contributed by Apple (now busy with Swift) and Google (busy with Carbon/Rust).
