C++ Logo


Advanced search

Re: std::span

From: Mario Charest <stayprivate_at_[hidden]>
Date: Sun, 19 Apr 2020 16:24:26 -0400
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.

> 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

Received on 2020-04-19 15:27:34