On Tue, Nov 14, 2023 at 10:04 AM Hewill Kang via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

I don't think there's anything special about `ms[0,0,...]` or
`ms[ms.extent(0)-1,ms.extents(1)-1,...]`. They certainly don't represent
"front" or "back" in the same way as in a std::list, for example. They
represent "upper left" and "lower right"... except that I think you might
be able to set the layout policy so that they represent "lower left" and
"upper right," or anything in between, maybe?
Notice that even e.g. std::set fails to provide front() and back()
accessors. And there I've actually (more than once) *wished* for a front()
accessor, as in "get me the least item in this ordered set"!
Personally I would like to have `front/back` for `set` and friends, but I
see no benefit to `front/back` for mdspan.

Cheers,
Arthur