Date: Sun, 19 Apr 2020 16:08:51 +0000
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.
--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.
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.
--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
Received on 2020-04-19 11:11:49