>
> (1) [...] 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.


This is a great point, thanks! I agree that variadic templates `at(...)`
are *new* to the standard, and when I try to spell out the "*Effects*:
Equivalent to:" wording that fits it, it's not as straightforward as it
seems, which is indeed something worth considering.

So I think `mdspan::at` deserves its own paper, perhaps discussing the
rationale for further providing `front()` and `back()`? Because in my
opinion there is also value in these two, the former eliminates the need
for spelling `ms[0,0,...]`, and the latter simplifies
`ms[ms.extent(0)-1,ms.extents(1)-1,...]`, which may be convenient for users.

Hewill

Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]> 於
2023年11月14日 週二 上午1:52寫道：

> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>