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.
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?