On Sun, Apr 19, 2020 at 4:03 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.
>
>
> 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.
>
>
Indeed.


> 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().
>

In my book, that's a good argument, Thank you sir.


> , 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
>