On Sat, 30 Nov 2019 at 17: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.

That's hardly a plausible explanation, because such projects can
simply choose to never call an at().

> 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.

For heaven's sake, that brings in ADL, which is hardly an improvement
over a simple member
function that does what other member functions already do.