On Sun, 19 Apr 2020 at 18:54, Tony V E <tvaneerd@gmail.com> 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.