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.

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

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