> Ergo we didn't think at() was worth the effort.
Well, we also thought it's bad because it goes against our (new)
dogma, so it was tossed out of the window, thus
creating an API that is inconsistent.
During the span discussions, one of the arguments presented was because span is not a container, it doesn't have to be consistent with containers. For me, things like consistency, interoperability and as close to a drop-in replacement as possible are very important and not dismissed lightly.
There were at least three inconsistencies span has compared with containers that didn't have to be there:
- signed size() (and the related index_type instead of size_type)
- lack of comparison operators
- at()
A number of us fought what we considered the most egregious of these, signed size(), but that took a lot of time and energy to do so.
Had we been redesigning the entire standard library from scratch (as opposed to designing something that should be interoperable with the C++ Standard Library and those who based their libraries on that design), I would have fought against at() in any form for the reasons John McFarlane and JeanHeyd Meneide have already brought up. Most out of range accesses are programming bugs, and contracts, not exceptions, will be a better way to handle those. The few remaining cases just aren't common enough to require standard support.