libstdc++: Handling user-defined interlike object in submdspan.

[Tomasz Kaminski]

On Tue, Sep 30, 2025 at 11:05 AM Luc Grosheintz <luc.grosheintz@gmail.com>
wrote:

>
> On 9/30/25 10:01 AM, Tomasz Kaminski wrote:
> >>
> >> I canonicalize tuple-like to `std::tuple`s of possibly wrapped
> >> index_type; and not to stride<*, *, std::cw<1>>.
> >>
> >> The advantage is that the preconditions remain the same, because
> >> tuples still exist, it's just that we don't encounter as much
> >> variability but the kinds of objects remain the same.
> >>
> >> Generally, and as written in the paper, it does make sense to maybe
> >> not canonicalize things like:
> >>
> >>     - std::array<index_type, 2>
> >>     - std::tuple<std::constant_wrapper<index_type, *>,
> >>                  std::constant_wrapper<index_type, *>>
> >>
> > Note that pair-like for the submdspan is representing [begin, end) range,
> > while the strided_slice has [begin, offset, stride)?
> >
>
> Yes, the thought is that
>    strided_slice{begin, end - begin, std::cw<1>}
> is a less direct way of expressing the idea. So users
> might opt for one of the other two instead. If we allow
> those to be passed through unchanged, they'll not have to
> worry about optimizing their code by making sure they
> use stride_slice{..., std::cw<1>}, it would just work.
>
Note, that strided_slice{..., std::cw<1>} may still be passed, so I do not
see how that removes the number of cases that may be optimized.
Canonicalization is strictly reducing the number of cases that user defined
mappings needs to handle.


>
> >
> >>
> >> because those are very natural ways of specifying that kind of slice.
> >> Therefore, even if there's a cost to canonicalization, every kind of
> >> slice has a convenient canonical form (that users can provide to skip
> >> canonicalization).
> >>
> > I do not think there should be differences between canonical forms of
> > strided_slice and pair_like, they represent the same concept. And
> > This should reduce the number of various concepts that we need to handle.
> > Note that the __first, __last functions are now completely gone from the
> > wording.
>
> I agree that multiple canonical forms is odd. On the other hand
> it's mentioned/suggested in the paper that standardized mapping
> may do less canonicalization:
>
>
> https://isocpp.org/files/papers/D3663R3.html#submdspan-can-skip-canonicalization-for-standard-layout-mappings

Standard mapping are required to  strided_slice{..., std::cw<1>} anyway,
and
I would prefer to avoid having two code paths, one for standard mapping and
other
for user-defined mappings, if that is not proven strictly necessary.


>
> >
> >
> >>
> >> Is it okay to send this variation as a v1? Naturally, you can then
> >> say: nope, do the full P3663 please.
> >>
> > You can send that of course, but after rewriting the whole wording
> section,
> > I think the previous
> > specification was a bit of a dead end, so I think I wil answer that way
> > anyway.
> >
> >
> >>>
> >>>
> >>>>
> >>>>>>
> >>>>>> The idea I'm pursuing is to follow the pattern of casting slices to
> >>>>>> "standard slices" immediately at the user-facing API layer, e.g.
> >>>>>>
> >>>>>>       template<typename _Slices...>
> >>>>>>       constexpr auto
> >>>>>>       submdspan_extents(_Slices... __slices)
> >>>>>>       {
> >>>>>>         return
> >> __submdspan_extents(__slice_cast(std::move(__slices))...);
> >>>>>>       }
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250930/c37438c8/attachment.htm>