On Sun, Apr 19, 2020 at 8:55 AM Tony V E via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

Yep that's how string_view and array do it, did not check the others. In
gcc:__throw_out_of_range_fmt and clang __throw_out_of_range_fmt(). These
function are already present and generic are ready to be used.


> Ergo we didn't think at() was worth the effort.
>
>
We all pick our own battle.


> We make style decisions daily, whether we admit it or not. ‎Every API
> decision is a style decision.
>

I can totaly appreciated the challenges that comes with that. Just which
the same decision logic that applied to every other container/view would
have been apply to span.


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