Date: Sun, 19 Apr 2020 12:27:08 -0400
On Sun, Apr 19, 2020 at 12:08 PM Robert A.H. Leahy <rleahy_at_[hidden]> wrote:
> With "real" containers (as opposed to views) a bounds check is truly
> meaningful. Since a std::vector owns and manages its storage it can perform
> bounds checks which establish whether the given index is truly valid.
> std::span (being a view rather than a "real" container) does not own or
> manage its storage so a bounds check only means something if and only if
> the viewed storage is still valid and the bounds used to construct the
> std::span are correct (neither of which std::span can independently
> verify).
>
> Following this line of reasoning it could be argued that providing
> std::span::at gives a false impression: A hypothetical std::span::at can't
> give the kinds of guarantees that std::vector::at does.
>
>
So span::at gives less guarantees than vector::at. It says "you are in
range of this span", but it doesn't say that there is an item there. You
don't have a range logic error, but you could still have a lifetime logic
error.
Interesting.
--Robert
>
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Tony V E via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Sunday, April 19, 2020 11:54
> *To:* Ville Voutilainen <ville.voutilainen_at_[hidden]>; sotrdg sotrdg via
> Std-Proposals <std-proposals_at_[hidden]>
> *Cc:* Tony V E <tvaneerd_at_[hidden]>
> *Subject:* Re: [std-proposals] std::span
>
> Yes, we should keep different styles in mind. However,
>
> I think programming style was part of the reason we left at() out, whether
> we want to admit it or not.
> It uses std : : logic_error, which is practically an oxymoron. If there
> was an error in logic, then why trust the code to properly catch the error?
>
> If we thought at() was important, then the <span> implementation could use
> and link against a function throw_out_of_range_for_span(), keeping string
> out of the header, and being terminate or noop for freestanding.
>
> Ergo we didn't think at() was worth the effort.
>
> We make style decisions daily, whether we admit it or not. ‎Every API
> decision is a style decision.
>
> Sent from my BlackBerry 10 smartphone.
> Original Message
> From: Ville Voutilainen
> Sent: Sunday, April 19, 2020 11:37 AM
> To: sotrdg sotrdg via Std-Proposals
> Cc: Tony V E
> Subject: Re: [std-proposals] std::span
>
> On Sun, 19 Apr 2020 at 18:31, Tony V E via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Or you could stop using at.
>
> Or program in perl, where despite some of the leaders being far more
> religious than we are, they are also far
> less dogmatic about what programming styles should be used.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> With "real" containers (as opposed to views) a bounds check is truly
> meaningful. Since a std::vector owns and manages its storage it can perform
> bounds checks which establish whether the given index is truly valid.
> std::span (being a view rather than a "real" container) does not own or
> manage its storage so a bounds check only means something if and only if
> the viewed storage is still valid and the bounds used to construct the
> std::span are correct (neither of which std::span can independently
> verify).
>
> Following this line of reasoning it could be argued that providing
> std::span::at gives a false impression: A hypothetical std::span::at can't
> give the kinds of guarantees that std::vector::at does.
>
>
So span::at gives less guarantees than vector::at. It says "you are in
range of this span", but it doesn't say that there is an item there. You
don't have a range logic error, but you could still have a lifetime logic
error.
Interesting.
--Robert
>
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Tony V E via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Sunday, April 19, 2020 11:54
> *To:* Ville Voutilainen <ville.voutilainen_at_[hidden]>; sotrdg sotrdg via
> Std-Proposals <std-proposals_at_[hidden]>
> *Cc:* Tony V E <tvaneerd_at_[hidden]>
> *Subject:* Re: [std-proposals] std::span
>
> Yes, we should keep different styles in mind. However,
>
> I think programming style was part of the reason we left at() out, whether
> we want to admit it or not.
> It uses std : : logic_error, which is practically an oxymoron. If there
> was an error in logic, then why trust the code to properly catch the error?
>
> If we thought at() was important, then the <span> implementation could use
> and link against a function throw_out_of_range_for_span(), keeping string
> out of the header, and being terminate or noop for freestanding.
>
> Ergo we didn't think at() was worth the effort.
>
> We make style decisions daily, whether we admit it or not. ‎Every API
> decision is a style decision.
>
> Sent from my BlackBerry 10 smartphone.
> Original Message
> From: Ville Voutilainen
> Sent: Sunday, April 19, 2020 11:37 AM
> To: sotrdg sotrdg via Std-Proposals
> Cc: Tony V E
> Subject: Re: [std-proposals] std::span
>
> On Sun, 19 Apr 2020 at 18:31, Tony V E via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Or you could stop using at.
>
> Or program in perl, where despite some of the leaders being far more
> religious than we are, they are also far
> less dogmatic about what programming styles should be used.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- Be seeing you, Tony
Received on 2020-04-19 11:30:22