>Why go through all the trouble to make a better array, and require the user to call a special .at() function to get range checking rather than the other way around?

Because the point was not to make an array type that's safe by default, but rather to make an array type that behaves like an object, and can be returned, copied, etc. I mean, I agree with you, I think operator[]() should range-check by default, but you're simply misunderstanding the rationale for the class.

▲

StillBored 4 days ago | parent [-]

Which goes to the GP's point, which is that security and robustness are not on the radar.

And my point in providing a concrete example, where a decision was made to prioritize unsafe behavior in a known problematic area, when they could just as well have made a half dozen other decisions which would have solved a long standing problem rather than just perpetuating it with some new syntactic sugar.

	▲	fluoridation 4 days ago \| parent [-]
		I didn't dispute that, I was simply addressing the point about std::array. The class is not meant to be "arrays, but as good as they could possibly be". It's "arrays, but as first-class objects instead of weird language constructs". That said, making std::array::operator[]() range-checking would have been worse, because it would have been the only overload that did that. Could they have, in the same version, made all the overloads range-checking? Maybe, I don't know.