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.