Take expected (which missed C++ 20 but may land in C++ 23). The idea here is like Rust's Result type†, but C++ lacks a sum type so it's instead presented a bit like a smart pointer. You check it for errors and then just dereference expected to get your answer if there weren't any errors. Simple. If you can't be bothered to do error-checking, no worries, dereferencing expected when it's an error throws an exception, and your usual C++ exception handling applies.
But no, the committee says this doesn't look dangerous enough to us, so they required it to be rewritten to say dereferencing expected when it's an error is Undefined Behaviour instead of throwing an exception.
Imagine deliberately adding more Undefined Behaviour to a programming language (technically in this case the language's standard library) in response to work to compete with safer languages. It's an act of self-sabotage without question.
† Unlike exceptions, in Result your error is just more data, to examine, process, store and use now or later or not at all at your option. An exception changes control flow in the program when the error occurs, which may not be what you need at all. This is crucial to some designs.
Yeah, the "there should not exist any language underneath besides Assembly" motto pushed to extreme, is what might eventually sink all efforts to make C++ safer alternative than plain old C.
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.
std::array will instantiate function templates for all used array sizes, lengthen compilation time, and be hard to use across separately-compiled code without putting code into headers. It has its uses, but more often I'd prefer T[N] with bounds-checking, and, in another world, a builtin variably-sized, non-resizable array type; basically a sort of absl::FixedArray[1], but with the semantics of operator[] and at() reversed, so that bounds-checking is the default. Sadly, nothing like that is included in the standard, so won't be a lingua-franca.
That is the thing, the standard doesn't require bounds checking for operator()[], while it does require for at(), but it doesn't forbid it either, it is up to the implementations.
I don't follow this logic. If we just wanted to do everything the way C/C++ does it, we'd be using C/C++, and Rust wouldn't exist.