On Sat, 30 Nov 2019 at 22:01, Nevin Liber via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Sat, Nov 30, 2019 at 1:21 PM Lyberta via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Anyway. My fundamental opinion is that operator[] should do bounds
>> checking while unsafe_at() should not because it is clearly named unsafe.
>
>
> Should all functions which have preconditions on calling them be named unsafe_*? I would not want to call unsafe_dereference(ptr) instead of *ptr each and every time I needed to dereference it (for example). I'm generally against verbosity for common cases.
>
> IMO, at() was a mistake, as the number of people who call it in the name of "defensive programming" far outweighs the few that call it to sanitize input.

*baffle* but 'defensive programming' was NEVER the argument of (some
of) those who advocated for functions that
would throw on logic errors. We have a serious selection bias problem
here. (Some of) The advocates of 'defensive programming'
are indeed lecturing the rest of the world about how to program, and..
well. The codeofconduct prevents me from providing
the true dulcet tones that I have, but as perhaps insinuated by the
previous statements I have made, it's unwise
to make cross-domain claims about specific domains when the people
making the cross-domain claims haven't
got the slightest clue about the domain-specific problems that working
programmers try to solve.

> As someone who has already fought multiple battles for span, it would take a lot to goad me into presenting such a paper. I would, however, be likely to support such a paper should it be presented to the committee.

Same here, except that I haven't spent any of the sort of time on span
as you have.

> IMO, it is way too late to try and get this added to C++20.

Oh, I didn't even think that was an aspect of this. For C++20, the
answer is "hell no, F*** no".