>
> In most of the meetings where span.at was discussed there seemed interest
> that this should be done in another paper. mdspan was specifically called
> out. There was no more general reference to view_interface. Are you willing
> to be among the lead paper(s) authors in this regard?


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?

Hewill

Jarrad Waterloo <descender76_at_[hidden]> 於 2023年11月13日 週一 下午8:52寫道：

> In most of the meetings where span.at was discussed there seemed interest
> that this should be done in another paper. mdspan was specifically called
> out. There was no more general reference to view_interface. Are you willing
> to be among the lead paper(s) authors in this regard? I don't mind being a
> scribe and using the span.at as a starting point but I am not
> intimately familiar with either mdspan or view_interface. Also at least one
> of the authors of mdspan expressed interest in this as well, I do not know
> which.
>
>
> On Mon, Nov 13, 2023 at 5:10 AM Hewill Kang via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hey C++ folks,
>>
>> I was surprised that C++26 actually introduced `.at()`
>> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2821r4.html>
>> for `span` (which throws an exception) , even though I was sure that this
>> function was initially rejected by the committee when `span` was first
>> introduced.
>> So, should `.at()` be also introduced for `view_interface` to ensure such
>> consistency, so that all range adaptors have safe random-access methods as
>> other containers in the standard?
>>
>> ```cpp
>> template<class D>
>> class view_interface {
>> private:
>> constexpr D& derived() noexcept {
>> return static_cast<D&>(*this);
>> }
>>
>> public:
>> // [...]
>> template<random_access_range R = D>
>> constexpr decltype(auto) operator[](range_difference_t<R> n) {
>> return ranges::begin(derived())[n];
>> }
>>
>> template<random_access_range R = D> requires sized_range<D>
>> constexpr decltype(auto) at(range_difference_t<R> n) {
>> if (n < ranges::distance(derived()) || n >=
>> ranges::distance(derived()))
>> throw_out_of_range();
>> return operator[](n);
>> }
>> };
>> ```
>>
>> I believe this can be seen as an enhancement, as it enables range
>> adaptors to have safe random-access operations, which were not available
>> before.
>> Additionally, `mdspan` also seems worth adding a corresponding variadic
>> `.at()`:
>>
>> ```cpp
>> template<class ElementType, class Extents, class LayoutPolicy =
>> layout_right,
>> class AccessorPolicy = default_accessor<ElementType>>
>> class mdspan {
>> // [mdspan.mdspan.members], members
>> template<class... OtherIndexTypes>
>> constexpr reference operator[](OtherIndexTypes... indices) const;
>> template<class OtherIndexType>
>> constexpr reference operator[](span<OtherIndexType, rank()>
>> indices) const;
>> template<class OtherIndexType>
>> constexpr reference operator[](const array<OtherIndexType, rank()>&
>> indices) const;
>>
>> template<class... OtherIndexTypes>
>> constexpr reference at(OtherIndexTypes... indices) const;
>> template<class OtherIndexType>
>> constexpr reference at(span<OtherIndexType, rank()> indices) const;
>> template<class OtherIndexType>
>> constexpr reference at(const array<OtherIndexType, rank()>&
>> indices) const;
>> };
>> ```
>>
>> What do you guys think? Does introducing `.at()` for the above two have
>> any observable value?
>>
>> Hewill
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>