On Sun, Apr 19, 2020 at 3:04 PM Nevin Liber via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Apr 19, 2020 at 11:00 AM Ville Voutilainen via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> > 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.
>

It's actually somewhat worse than this. span used to have comparison
operators, and then people fought to remove them.

At least span simply never had at() to begin with. P1024R0 proposed adding
it (along with a bunch of other members), but that part of the proposal was
rejected in Rapperswil.

Barry


>
>
> 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.
>
> But given that we've been shipping containers with at() for over two
> decades, span should have had at().
>
>
> This puts me in the uncomfortable position that I don't believe it is
> worth the cost in committee time to pursue adding at(), but if it were to
> make it to a vote, I would probably vote for it unless there were strong
> technical reasons not to.
> --
> Nevin ":-)" Liber <mailto:nevin_at_[hidden]
> <nevin_at_[hidden]>> +1-847-691-1404
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>