Dear Mario,

     I think you're right here: the consistency of the API should have been
considered. From my perspective very few people used .at(), but that was
just my own lack of experience showing, rather than a universal truth.

     I think .at() would be a good addition, now that I spend more time
thinking about it. When I first implemented <span> for libstdc++ I noticed
that it lacked `size_type` and other small things for consistency reasons.
These were fixed by Nevin Liber in his paper; we also didn't have
operator== nor did we have at(). The more I think about it, the more we
should have included it.

     For all the reasons discussed in this thread, we absolutely would have
been able to mitigate the compile-time cost. That would require linking
against a library rather than being header-only or using very specific
internals, which some libraries are already doing. Alas, in fixing <span> I
did not propose any further changes. I'm sorry; this might be something
worth fixing for C++23, but with operator== out the window as well I think
we've long since sailed the ship of "consistent, easy-to-use API".

     The free function will probably be your best bet. I'm sorry for the
pain we cause you down the line.

Best Wishes,
JeanHeyd


On Sun, Apr 19, 2020 at 1:47 PM Marcin Jaczewski via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Btw why `at` need at all `<string>` header? Or even `<exception>`?
>
> Could standard require it call global function `void
> throw_out_bound_exception() noexcept(false);` that take only `const
> char*`?
>
> This will solve all header pollution without changing functionality a
> bit. This could be used by end user too to reduce need to include
> multiple headers to throw some standard exceptions.
> You should pay only for things that you REALLY need.
>
>
> niedz., 19 kwi 2020 o 19:07 Ville Voutilainen via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> > On Sun, 19 Apr 2020 at 20:05, Tony V E <tvaneerd_at_[hidden]> wrote:
> >
> > > If someone wrote a paper for span::at, and explained away all the
> "excuses" for not having it (ie header dependencies, etc), I might vote for
> it.
> > > Consistency is a strong argument for any API decision.
> > >
> > > Or maybe it was discussed and voted already and best not to rehash?
> >
> > An uphill battle. Sun Tzu told me not to do that. We have better
> > things to do. Just wrap it and move on.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>