On Mon, Nov 13, 2023 at 12:34 PM Matthew Taylor via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > Thanks for your feedback. Do you think these two need to be treated as
> separate modules, i.e. they should be *two* papers, or can they be
> considered together as one, i.e. i.e. one paper covering both?
>
> That's up to you, but don't forget that a paper either is accepted as it
> is or sent for revision; and it wouldn't be the first time that an author
> decided to split his proposals up into multiple papers [...]
>

I agree — "it depends." :)
FYI, Hewill, I was in the room for the LWG discussion (as I assume was
Jarrad) and I can tell you that:

(1) The question "should we do this for `mdspan` too?" *was* raised by LWG.
I (and probably others too) pointed out that the answer was probably "yes,"
but that a multi-argument `.at(x,y,z)` would be completely novel in the STL
and therefore *very* clearly "design work" not to be snuck in by LWG; it
needs a paper. Such a paper seems non-controversial to me, but who knows.
You should contact the mdspan folks, e.g. Mark Hoemmen, Christian Trott. I
know Christian is pursuing a paper on an owning `mdarray` — I'd ask him,
does `mdarray` support `.at()`? Why or why not? *If* you can't convince
those folks to propose `mdarray.at()`, then it certainly doesn't belong in
`mdspan`; the whole point of the non-owning span is to provide an
API consistent with the owning container. But probably it should be added
to the API of both span and container.

(2) The question "should we do this for arbitrary `view_interface`,
arbitrary random-access ranges" did *not* come up in LWG while I was there.
That seems more controversial to me. Now, the success of span.at() proves
that "it throws, can't have it" is no longer a valid argument — thank
goodness we've finally figured out how to let a freestanding implementation
line-veto individual member functions. But you'll still have the
consistency argument — you want to provide `.at()` for all
view_interface-derived views, but what about views that don't derive from
view_interface or view_base? Will it end up being "implementation-defined"
whether any given std::views::foo provides .at(), depending on whether it's
implemented in terms of view_interface or not? Will this end up being yet
one more member function that all views must de-facto provide, and if so,
will you propose adding it to the random_access_range concept?
Should it just be a free function instead?
    template<random_access_range R>
    decltype(auto) std::ranges::at(R&& rg, range_size_t<R> i) {
        return (i < std::ranges::size(rg)) ? rg[i] : (throw
std::out_of_range("oops"));
    }
If so, should it be a CPO? If so, should it do an ADL lookup for `at`?
(please god no, to the last of these questions; but otherwise I'm pretty
neutral on them)

–Arthur