I would first measure if there are performance issues adding at to the
span's operator [] other then the performance issues with the at in
general. If there are no performance issues with the operator[] then a
justification to adding at to std::span is to adding noexcept the
operator[] and keeping the exception version with the at operator. This
might be another benefit to low latency C++ programmers to use std::span's
operator[] as exceptions can be slow. The main issue I see is should the
operator[] do any bound checking I am not sure that should be the case with
C++ programmers who are looking for the highest performance.

On Thu, Nov 28, 2019 at 5:37 AM Roman Babinicz via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> Could we add operators at() to span<> container?
>
> value_type & at(size_type n);
> const value_type & at(size_type n) const;
>
> they would have same behaviour as in vector, array - that is throws an
> exception if n is outside of size of the container.
>
> 1) can we have that?
>
> 2) if yes, then should I write a proposal paper or how else to help in
> this?
> Can it make it to C++20?
>
> Imo it is a notable defect that span can not be a drop in replacement
> for code taking a (reference to) array/vector that is using at().
>
> 3)
> By the way, in case of span that has specific size (not dynamic_extent)
> we could perhaps have a static assert and the function might be constexpr.
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>