libstdc++: Handling user-defined interlike object in submdspan.
Tomasz Kaminski
tkaminsk@redhat.com
Tue Sep 30 06:53:12 GMT 2025
On Tue, Sep 30, 2025 at 8:30 AM Luc Grosheintz <luc.grosheintz@gmail.com>
wrote:
>
>
> On 9/29/25 5:18 PM, Jonathan Wakely wrote:
> >>
> >> The question is should it support custom types that aren't copyable?
> >> (Everything is much easier if all types are move and copy
> >> constructable).
> >>
> >
> > I think this is in flux, via P3663, which is being reviewed by LWG at the
> > moment. The latest draft (with a lot of input from Tomasz) is
> > https://isocpp.org/files/papers/D3663R3.html
> >
>
> Thank you, that's interesting. I'll read it again more carefully, but
> it looks like the proposed casting layer is sensible; and might get
> added via P3663 (they call it canonicalization). I'll finish a v1
> with the casting layer.
>
My suggestion here would be to implement what P3663 is proposing
from the start. This is only observable for user-defined mappings, as they
will no longer obser other slice types than canonical ones.
As the paper touches a lot of wording, we have fixed some of the issues
as the drive-by there.
>
> >>
> >> 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/a8ebfdb4/attachment-0001.htm>
More information about the Libstdc++
mailing list