Subject: Re: [std-proposals] function at() for span<> that throws exception on out-of-range, like vector and array ::at()
From: Charles Milette (charlesmilette_at_[hidden])
Date: 2019-11-30 10:22:27
On Sat, 30 Nov 2019 at 10:44, Bjorn Reese via Std-Proposals
> 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
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.
STD-PROPOSALS list run by herb.sutter at gmail.com
Standard Proposals Archives on Google Groups