You are right that “major architectures” will not be an issue. But people assume portability when it comes to the C++ standard. The implication is that hardware-dependent functions will be left out unless extremely common. Some ISAs, mainly used in resource-constrained systems, have no support for and really don’t need anything beyond the basics.
If I am building the compiler for such hardware, I don’t support functions that are irrelevant to the hardware’s use cases. This is very common in embedded, where vendors might build their own compilers.
What does that mean in practice? People can’t reuse code that many compilers don’t support.
A bigger standard (more functions, more uncommon features) ->
Compilers will be more complex and expensive ->
Less likely that a typical compiler will support the standard fully ->
C++ standard will be less portable ->
The standard won’t be a “standard”
Today, most compilers don’t support C++17 and later. Many compilers and teams are totally fine sticking with C++11.
We aren’t trying to build a legacy for ourselves but serve billions of users; we are trying to maintain an “ISO Standard.” By definition, it must be fundamental and general purpose (of course, of the highest quality). Otherwise, the feature can very well be a library and integrated only by those who need it. A good standard must be small; less is more. WG 14 is doing a great job leaving unnecessary features for library developers. However, if an open-source library becomes popular and successful with invaluable implementation experience, it will have a smoother path toward standardization.
So why the same reason that would make WG 14 not want it in the standard not apply here?
This might not be a popular thing to say, but it is the reality: While Objective-C is a strict superset of C, C++ is a partial superset. C++ is not like those other aforementioned languages. The survival of C++ depends on C. Assume hypothetically that all system software ––which is written in C–– was magically rewritten in Rust. Outcome: Rust will replace C++.
Academia doesn’t teach people how folks in the industry make pragmatic decisions. We choose a tech stack that best suits the purpose, fits the budget and saves time. For us, C++ makes sense because it is:
A partial superset of C <- Interoperability, skillset and code reuse, etc.
High-level OO <- Productivity.
Otherwise, Rust and various high-level languages would do the job just fine. Without C, C++ will have no future in the industry. These two complement each other; they aren’t enemies or strangers.