On Sat, 30 Nov 2019 at 10:44, Bjorn Reese via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 2019-11-30 11:15, Eyal Rozenberg via Std-Proposals wrote:
> > What are the arguments against "at()", other than possibly being redundant?
>
> That it brings in exceptions, which are disable in many real-time and
> embedded projects.
>
> For instance P0829 proposes to remove std::array<T>::at() in
> freestanding mode.
>
> I reckon that the most viable approach forward is to introduce a free
> std::at() function, similar to std::get(). This makes it possible to
> have bounds check for types that do not support them, such as C arrays
> or std::span.
That breaks existing generic code operating on containers expecting an
at() member to
exist (not to mention std::span already won't work with those due to
lacking .at()),
and is much worse to write when chaining:

cont.at(otherCont.at(i)) vs std::at(cont, std::at(otherCont, i))

FYI I also don't like std::get and would have preferred to use
operator[] with the proposed
constexpr parameters on tuples instead.