If I may add my two cents, I think that adding a bounds checking access
function to span, it would be useful in code that needs it, and won’t harm
code that doesn’t. There are few cases where at is necessary, but in those
cases, having it available is better than doing it yourself.

On Fri, Nov 29, 2019 at 21:46 Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, 28 Nov 2019 at 15:46, Roman Babinicz <rb_at_[hidden]> wrote:
> > > I predict this to be an uphill battle. Some audiences think that at()
> > > should have never been
> > > in vector, and adding it to array was a mistake, and that that mistake
> > > shouldn't propagate
> > > any further. I would guess that some such audiences are co-authors of
> span.
> > >
> > > Personally, I think they're wrong, but I'm just giving you a heads-up
> > > that this is not going to be
> > > a trivial sale.
> >
> > Thanks for reply.
> >
> > I have additional arguments why should we provide the ::at() .
> >
> > This "battle" is generally happening here, on proposals mailing list, or
> > should some other place be contacted also?
>
> Ultimately, the "battle" will happen in the Library Evolution Working
> Group of the standards committee.
> This forum may provide you with potentially useful feedback, but at
> any rate, the feedback you
> receive here doesn't tilt any scales.
>
> > Does writing the (trivial) paper proposal possibly help by being a
> > formal proposal, or should it be done only after full consensus in
> > discussion?
>
> The consensus (or lack of it) of this forum has no binding effect.
>
> > Without at() in span:
> > - developers have to rewrite the existing code to be able to upgrade
> > the (&vector) function into a more modern span<> which slows down
> > adoption of span
>
> ..assuming that there's a large amount of code using at() on things
> like std::vector. If you
> wish to make that case, try to find evidence supporting that.
>
> > - developers who are used to at, will have to write own free-function
> > for it, or a small wrapper class around span - which is less readable:
> >
> > at(data,i) = min(10, at(old_data, i+offset) )
> > data.at(i) = min(10, old_data.at(i+offset) )
>
> ..but that doesn't look like a wrapper _class_ around span, that looks
> like a wrapper function.
> For getting what you want, i.e. type-semantics that suit your use
> cases, wrapping a class in
> the standard library is an approach worth looking at. If you don't
> like what span gives you,
> absolutely wrap it.
>
> > Personally I think it is good to by default write at() as the secure
> > code (at small cost), and only in places that are relevant to
> > performance change it to [] after careful review.
>
> Please be careful about claims that using at() is more secure. Such
> claims need evidence.
> An unexpected exception can very well be as insecure as an unexpected
> out-of-bounds access.
>
> > - array-bounds errors are one of most common sources of bugs and
> > exploits, and contribute to reputation of C++ being "error prone"
>
> I honestly don't know whether that's accurate, considering the
> recent&decent tools
> we have (like sanitizers). I'm perfectly willing to entertain that
> reputation being plausible, no
> question about it, but were I to repeat various presentations I've
> given over the years, C++
> is
> - a chainsaw
> - thus best handled by operators who have been trained at least to some
> extent,
> although maybe equipped with some amounts of protective gear designed
> by professionals
> - but it's also a chainsaw that does an intriguing triangle that few
> if any languages do,
> which is
> * automagic cleanup
> * static typing
> * customizable by-value semantics
>
> I am yet to see a language that can give me that, other than C++. C++
> also gives me high performance,
> in addition to that nice triangle(*). Having worked on, with, and in
> C++ for two decades, I would both love
> to keep it and also like throwing it into an ocean, but the technician
> in me says "you can't do that shit
> unless there's a practically deployable superior alternative that can
> solve the same problems, and hopefully
> more". And I, as always, have to agree with that technician.
>
> (*) And however many dimensions you want that tesseract to have, C++
> also has portability as one of its
> advantages.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>