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

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