On Saturday, the ISO C++ committee completed the second-last design meeting of C++26, held in Hagenberg, Austria. There is just one meeting left before the C++26 feature set is finalized in June 2025 and draft C++26 is sent out for its international comment ballot (aka “Committee Draft” or “CD”), and C++26 is on track to be technically finalized two more meetings after that in early 2026.
Because that’s not the sensible route in the future, whether we like it or not. Hardened STL is being announced in the papers as “we are going to start with these silly one-line fixes that in theory should perturb no one, but as we iterate over this we’re gonna start breaking things”, which is not what you want to hear from the default.
One good example: placing enforced bounds check into the
operator[]ofstd::array<>of all places. People keep telling me that I should be using std::array instead of normal C arrays, but then punish me for using std::array? That ends up making people revert to the True Old Ways That Work (aka: C arrays).Bounds checks are not punishing you. Obviously the right way to do this would be to make
operator[]be bounds checked by default but only if you use-std=c++29or whatever, and then also add a.at_unchecked()method for when you want to opt out of the bounds checks.What kind of barbarism is that?
Doing that kind of split would kill genericity (more than it already is). If I’m using
[]is because what I want is, more or less, to just access the value; not to maybe randomly and without any kind of source-level control or projected time/space boundaries go to the blockchain to check if the Rust devs are in the mood today to have blessed the given statement with the arguments given.Frick. At least give me something like
[checked(5)]or[unchecked(5)]for a more natural syntax. The more considering it has been possible to add compile-time checked access with something like[integral_constant<size_t,5>{}]since at least C++03! It just needs someone to propose a standardized notation shortcut. Or if there was some way to inquire orstatic_assertthat the checks on the natural syntax are actually elided if I’m doing them myself elsewhere. But at it stands, uglifying the syntax is the worst of all worlds.What on earth are you talking about? I honestly can’t even understand what objection you’re trying to make.
Wait, wait! Are you under the impression that
.at()is a function call andoperator[]is …not? What?