I don't see this part though. "Leave no room for a lower level language" doesn't require you to go around defining every mistake as Undefined Behaviour, that's crazy. A different part of the committee managed to see in 2021 that if your format can be statically detected as bogus (e.g. you tell the formatter you're giving it a string, then hand over a floating point type variable) then the compiler should be obliged to emit a diagnostic and give up compiling the program, not hand you a program that it knows can't work and enjoy your humiliation when it fails in production. That's the sort of safety improvement you'd want to see.
As I understand it the runtime performance-at-all-costs school, which includes people from Google, don't want the C++ language to be deliberately unsafe they just don't prioritize safety over performance. This group won't allow C++ to have runtime bounds checking for the array subscript operator or its overloaded equivalents and I think they're wrong about that, but it's not making the problem worse. Stuff like ranges, views and iterators (even though C++ iterators are incredibly ugly) mean in idiomatic C++ today you're rarely reaching for this particular gun that's supplied loaded and pointing directly at your feet. In contrast what was done to expected just seems like self-sabotage. If it's too slow then don't use it. Or rather, as these same people would be the first to point out, measure to check your intuition that it's too slow and only then if it really is don't use it.
That is exactly what I mean, the leave no language underneath agenda is being pushed by the performance at all costs crowd.
In all these years I have left RTTI enabled, used exceptions, tried to keep bounds checking enabled in STL types, and it was never an issue in production.
As I understand it the runtime performance-at-all-costs school, which includes people from Google, don't want the C++ language to be deliberately unsafe they just don't prioritize safety over performance. This group won't allow C++ to have runtime bounds checking for the array subscript operator or its overloaded equivalents and I think they're wrong about that, but it's not making the problem worse. Stuff like ranges, views and iterators (even though C++ iterators are incredibly ugly) mean in idiomatic C++ today you're rarely reaching for this particular gun that's supplied loaded and pointing directly at your feet. In contrast what was done to expected just seems like self-sabotage. If it's too slow then don't use it. Or rather, as these same people would be the first to point out, measure to check your intuition that it's too slow and only then if it really is don't use it.