Your four Examples are excellent. I do wish you'd present them in Tony-table form, though: IIUC today each of the four examples is ill-formed (rejected at compile-time), and after P4173 they'd all be well-formed and Do The Right Thing, is that correct?

The main thing I worry about is that your proposal essentially nerfs any optimization potential inside the implementation. You write:

> mdspan essentially treats multi-dimensional access as a layer on top of contiguous memory, rather than a generalized abstraction for any indexed data source.

But is it just "treating" multi-dimensional access as a layer on top of contiguous memory, interface-wise; or does mdspan internally implement multi-dimensional access as raw-pointer operations, in order to reduce code bloat and to reduce pressure on the compiler's optimizer? I fear mdspan does the latter.

So I fear that your proposal is basically asking implementors to implement (certain parts of) mdspan twice: one time for contiguous iterators, which can be lowered to raw pointers; and a second time (non-existent today, but forced by your proposal) for random-access-but-non-contiguous iterators, which will be forbidden to use any clever optimizations.

I'm not necessarily right about that fear; and even if implementors are forced to implement two codepaths, there's certainly precedent in the STL for that.

But basically this indicates that your D4173R0 is conspicuously missing an "Implementation experience" section.

Nit: "Lastest" should be "Latest."

Bikeshed: "__cpp_lib_iterator_accessor" should perhaps be "__cpp_lib_mdspan_iterator_accessor" for clarity.

Pre-existing nit: Your Mandates element has the words "is required to be"; that should be just "is". Do you feel like submitting an editorial PR for the pre-existing misuses of "is required to be" in [mdspan.accessor]?

You write:

> -3- Each specialization of iterator_accessor is a trivially copyable type that models semiregular.

Is this "trivially copyable" implementable? If iterator_accessor contains an I data member, it's not. At least this should say "iterator_accessor is trivially copyable if I is trivially copyable." Or, alternatively, add "Mandates: I is trivially copyable."

The latter would be really annoying IMHO. However, it brings me back to my first fear: Is there a reason that all accessors are currently specified to be trivially copyable? Does that help the implementor somewhere later on, that we can copy (a contiguous array of) accessors with memcpy without knowing their exact type? If so, then permitting `iterator_accessor` to be non-trivially copyable is going to be an implementation burden. So again, I want to see an "Implementation Experience" section and I want to see it deal with these (imagined/feared) optimization issues head-on.

Alternatively, if iterator_accessor does not contain an I data member, then why stop at "trivially copyable"? Why not specify that iterator_accessor is always an empty type? (And then, pre-existing, why do none of the other accessors bother to specify that? What data members are they imagined to have, then?)

Other than the big fear that this will turn out to be unimplementable for some technical reason, IMHO this sounds great. Again, those four Examples are very motivating.

HTH,

Arthur

On Wed, Apr 1, 2026 at 10:01 AM Hewill Kang via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hi, I wrote a paper on this: https://isocpp.org/files/papers/P4173R0.html
Thanks.

Hewill Kang <hewillk@gmail.com> 於 2026年3月30日週一下午8:33寫道：
Hi all,

Currently, although `mdspan` is designed as a general-purpose multiview, it mostly accepts a pointer and accesses different elements through a pointer algorithm.
However, I am not satisfied with these pointer-based mandates because I do not think they are much different from a general `contiguous_iterator`, which can be a common iterator such as `vector::iterator`.
If we look at the `default_accessor`, we can see the clue:

```cpp
template<class ElementType>
struct default_accessor {
using offset_policy = default_accessor;
using element_type = ElementType;
using reference = ElementType&;
using data_handle_type = ElementType*;

constexpr default_accessor() noexcept = default;
constexpr reference access(data_handle_type p, size_t i) const noexcept
{ return p[i]; }
constexpr data_handle_type offset(data_handle_type p, size_t i) const noexcept
{ return p + i; }
};
```
Then, upon closer inspection, we discovered that this is exactly the operation supported by C++20 `random_access_iterator`, i.e., `operator[]` and `operator+`.
Given this, I think we can introduce a new accessor class that wraps the `random_access_iterator`, for example:

```cpp
template<random_access_iterator I>
struct iter_accessor {
using offset_policy = iter_accessor;
using reference = iter_reference_t;
using element_type = remove_reference_t<reference>;
using data_handle_type = I;

iter_accessor() noexcept = default;
constexpr reference
access(data_handle_type p, std::iter_difference_t i) const
{ return p[i]; }
constexpr data_handle_type
offset(data_handle_type p, std::iter_difference_t i) const
{ return p + i; }
};
```

This fully inherits the natural characteristics of a `random_access_iterator`, which allows us to very easily make `mdspan`s with a wide variety of different `random_access_range`s, such as:

```
using Layout = std::layout_right::mapping<std::extents<int, 3, 3>>;

auto r = std::views::iota(0, 9);
auto ms1 = std::mdspan(r.begin(), Layout{}, iter_accessor<decltype(r.begin())>{});
/* 0 1 2
3 4 5
6 7 8 */

auto v = std::vector<bool>{true, false, true, false, true, false, true, false, true};
auto ms2 = std::mdspan(v.begin(), Layout{}, iter_accessor<decltype(v.begin())>{});
/* true false true
false true false
true false true */

std::vector<int> v1{1, 2, 3}, v2{4, 5}, v3{};
std::array a{6, 7, 8};
auto s = std::views::single(9);
auto r3 = std::views::concat(v1, v2, v3, a, s);
auto ms3 = std::mdspan(r3.begin(), Layout{}, iter_accessor<decltype(r3.begin())>{});
/* 1 2 3
4 5 6
7 8 9 */
```
Demo: https://godbolt.org/z/xb5vrejba

I think this is a very useful utility.
Based on C++26, we have a large majority of range adaptors in `<ranges>` that can support `random_access_range`.
Introducing this `accessor` makes them better integrated with `mdspan`, which also opens the door for third-party custom range types.

What do you think? Appreciate any feedback.

Hewill

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals