Currently, the creation of `mdspans` with `iterator_accessor` relies on the
following CTAD:
```
template<class MappingType, class AccessorType>
    mdspan(const typename AccessorType::data_handle_type&, const
MappingType&,
           const AccessorType&)
      -> mdspan<typename AccessorType::element_type, typename
MappingType::extents_type,
                typename MappingType::layout_type, AccessorType>;
```

We must spell with
```
 auto _3x3 = std::layout_right::mapping(std::extents(3, 3));
 auto ms = std::mdspan(r.begin(), _3x3, std::iterator_accessor(r.begin()));
 ```

A subsequent question is, once we have an `iterator_accessor`, should we
enhance mdspan's CTAD so that:

```
  auto ms = std::mdspan(r.*begin*(), 3, 3); // call *begin*() instead of
*data*()
```

Works well? For example, enhance `ElementType*` parts in the current CTAD
for `random_access_iterator`:
```
template<random_access_iterator I, class... Integrals>
    requires ((is_convertible_v<Integrals, size_t> && ...) &&
sizeof...(Integrals) > 0)
    explicit mdspan(I, Integrals...)
      -> mdspan<typename *iterator_accessor*<I>::*element_type*,
                extents<size_t, maybe-static-ext<Integrals>...>,
                layout_right,
                *iterator_accessor*<I>>;
```
This eliminates the need for spelling of *r.begin()* twice.
However, it's uncertain whether this *relaxation* for users dealing with
contiguous_iterator/random_access_iteratorer instead of a raw pointer is
good.

Hewill Kang <hewillk_at_[hidden]> 於 2026年4月4日週六 上午11:54寫道：

> Thank you, that makes sense.
> I updated the paper.
>
>
>
>
> Mark Hoemmen <mark.hoemmen_at_[hidden]> 於 2026年4月4日週六 上午3:16寫道：
>
>> On Fri, Apr 3, 2026 at 11:27 AM Hewill Kang <hewillk_at_[hidden]> wrote:
>> >>
>> >> Also, iterator_accessor has to deal with pointers as a special case of
>> >> iterators, so it should have the same safeguard as default_accessor and
>> >> friends against converting a pointer-to-derived to a pointer-to-base.
>> >
>> >
>> > That's reasonable, thank you. I updated the paper.
>> >
>> > This is the current final version of the paper:
>> https://isocpp.org/files/papers/P4173R0.html
>> > And implementation with libstdc++: https://godbolt.org/z/86MKa3oa5
>>
>> Would you consider making those conversion operators to
>> `default_accessor` explicit?
>>
>> I ask because container authors sometimes provide iterators that model
>> `contiguous_iterator` but do run-time bounds checking. Implicit
>> conversion from `iterator_accessor` to `default_accessor` would
>> silently strip away this protection.
>>
>> Thanks!
>> mfh
>>
>>
>> >
>> > Thanks.
>> > Hewill
>> >
>> > Ell <ell.ell.se_at_[hidden]> 於 2026年4月3日週五 上午2:48寫道：
>> >>
>> >> On Thursday, April 2nd, 2026 at 8:24 PM, Mark Hoemmen via
>> Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >>
>> >> > >> Have you considered adding converting constructors so that users
>> can
>> >> > >> go from an iterator-to-nonconst to an iterator-to-const?
>> >> > >
>> >> > > The proposed wording has the following converting constructors:
>> >> > >
>> >> > > template<convertible_to<I> I2>
>> >> > > constexpr iterator_accessor(iterator_accessor<I2>) noexcept {}
>> >> > >
>> >> > > I think it's enough to cover it?
>> >> >
>> >> > The analog of this is enough for `default_accessor`, but that only
>> has
>> >> > to deal with pointers. If I is constructible from I2, but I2 is not
>> >> > convertible to I, then the same should be true of the accessor. As a
>> >> > result, mdspan conversion would work in the same way as accessor
>> >> > conversion. This is the design intent of mdspan.
>> >> >
>> >>
>> >> Also, iterator_accessor has to deal with pointers as a special case of
>> >> iterators, so it should have the same safeguard as default_accessor and
>> >> friends against converting a pointer-to-derived to a pointer-to-base.
>>
>