>and also that a language doesn't need base64 in its stdlib because C and C++ don't have it
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.
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.
For anything else I don't have any major complaint.
[1]: <https://github.com/abseil/abseil-cpp/blob/master/absl/contai...>
https://docs.microsoft.com/en-us/visualstudio/debugger/how-t...
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.
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.
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.
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.