On Sun, Apr 19, 2020 at 12:00 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Sun, 19 Apr 2020 at 18:54, Tony V E <tvaneerd_at_[hidden]> wrote:
> > 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?
>
> Because the code that catches the error is sometimes or even often
> written by different people.
>

Yep. Also, the alternative to "why trust the code once you've found an
error" is that you _do_ trust code when you haven't found an error,
implying there exists bug-free code, which is unlikely.


> > 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.
>
> 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.
>
>
Yes that is exactly what we did, and is the result.

Now _maybe_ we thought it caused include dependency problems or we thought
span should bounds check with contracts or something,
but I think we made a dogmatic decision.

I'm not even saying I agree with the decision. I'd be fine with at(). (It
isn't my biggest issue with span either way.)

> We make style decisions daily, whether we admit it or not. ‎Every API
> decision is a style decision.
>
> That's a poor excuse for making style decisions that we are not as a
> group all that well-versed to make.
>

If LEWG is not equipped to make these decisions, then we have a bigger
problem.

-- 
Be seeing you,
Tony