libstdc++: questions about P3663

[Tomasz Kamiński]

pt., 31 paź 2025 o 21:39 Tomasz Kamiński <tomaszkam@gmail.com> napisał(a):

>
>
> pt., 31 paź 2025, 19:46 użytkownik Mark Hoemmen <mark.hoemmen@gmail.com>
> napisał:
>
>> Hi Luc and other libstdc++ devs!
>>
>> Jonathan Wakely pointed out your questions about P3663 (
>> https://gcc.gnu.org/pipermail/libstdc++/2025-October/064198.html ).
>> I'll answer them here.
>>
>> > 1. What are the requirements for user provided integer-like objects
>> (when used as slices)? Do they need to have copy and move ctors?  There's a
>> few locations where non-canonicalized slices are copied, e.g. when passed
>> to `submdspan_canonical_slices`.
>>
> The specified calls to `submdspan_canonical_slices` must compile, that's
> all requirements.
>
With the canonization in place, we may consider specifying the slices to be
always moved,
further reducing the requirements on the input types.

>
>> The original `submdspan` proposal P2630 never made this clear.  P3663
>> doesn't try to resolve that.
>>
>> The reference implementation copies slices all over the place.  I
>> think it's fair to assume that slice specifiers are copyable and
>> movable.
>>
>> Design intent for what you call "user provided integer-like objects"
>> includes "strong typedefs," say special index types that people use in
>> nested for loops to make sure that they aren't getting the order of
>> indices wrong (that implies wrapping mdspan's `operator[]`).  Those
>> normally don't need the full set of integer operations, just what they
>> would need to make sense in a for loop.
>>
>> > 2. What happens if in the future the standard wants to add a new kind
>> of *canonical* selection? For example, block-wise selection: pick N, skip
>> M, pick N, skip M, etc. This can't be expressed by any of the current
>> canonical slices (currently there's also no layout to express this idea,
>> but presumably it would be added at the same time).
>>
>> P3663 makes it possible for the Standard to do this in the future.
>> Please see Section 4.6, "WG21 may add a new slice category" (
>>
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3663r3.html#wg21-may-add-a-new-slice-category
>> ).
>>
>> The idea is that it's never a breaking change to go from "ill-formed"
>> (status quo after adopting P3663) to "well-formed and well-defined"
>> (after hypothetical addition of a new kind of selection).
>>
>> > 3. Is there a way to `static_assert` the mandate that something is a
>> "submdspan slice type for IndexType"?
>>
>> If you're referring to [mdspan.sub.helpers] 6, in the specification of
>> _`canonical-slice`_, then the way that you implement the Mandates is
>> by means of the code in [mdspan.sub.helpers] 7.  That code will be
>> ill-formed otherwise.
>>
>> We do it that way because you can't write an expression (to use in a
>> `static_assert` or the definition of a concept) to express that a
>> structured binding declaration is well-formed.
>>
>> > 4. The notion of "unit-stride slice" is false for pairs and tuples,
>> even though they intuitively have unit strides. By renaming the concept
>> "canonical unit-stride slice", the name would match my intuition again.
>>
>> I debated that with Tomasz (CC'd) and lost ; - ) .  If I remember
>> right, he explained that the Standard never needs a non-canonical
>> unit-stride slice, so there's no reason to define that idea.  The
>> Standard defines terms only because it uses them.
>>
>> > 5. There's a notion of "lower bound of the submdspan slice range" which
>> is also used in contexts where the slice could be empty, e.g.
>> `strided_slice(n, 0, 1)`. This represents the same empty interval
>> regardless of the value of `n`, the question is what is the "lower bound"?
>>
>> [mdspan.sub.overview] 8.2 defines the lower bound for this case as the
>> offset `n`.  The upper bound is also `n` for this case.
>>
>> > Concretely, let `n == exts[i]`. Then, is `pair{n, n}` a valid slice for
>> dimension `i`?
>>
>> Yes, it is.  Acceptance of the Proposed Resolution of LWG Issue 4060 (
>> https://cplusplus.github.io/LWG/lwg-defects.html#4060 ) at the St.
>> Louis meeting last year fixed this.
>>
>> > It sounds like yes, because the condition:
>> >
>> > > the kth interval of e contains the submdspan slice range of s for the
>> kth extent of e;
>> >
>> > is satisfied due to the interval being empty. By the same logic,
>> `pair{n+1, n+1}` should also be valid, but `pair{cw<n+1>, cw<n+1>}` isn't,
>> because it's not a slice type for the kth extent.
>>
>> That's a good point.  `pair{cw<n+1>, cw<n+1>}` would have a
>> canonicalization that is invalid per [mdspan.sub.overview] 9.1.1.
>>
>> We should file an LWG issue about this.  Would you like to do it?
>>
>> > 6. I'd like to suggest adding "canonical" to "valid submdspan slice for
>> the kth extent of e," because:
>> >
>> > - a "submdspan slice type for IndexType" is not required to be
>> canonical,
>> > - there's a couple of related concepts that explicitly mention the word
>> canonical,
>> > - it makes it harder to know when `SliceSpecifiers` refer to canonical
>> slices, since that property isn't mentioned and only implied by "valid
>> submdspan slice for the kth extent of e".
>>
>> I'm not quite sure what you mean.  Would you like the phrase to be
>> "valid canonical submdspan slice..."?
>>
>> The hierarchy works like this:
>>
>> 1. `submdspan` slice type for `IndexType`: lots of types, possibly out of
>> bounds
>> 2. canonical `submdspan` slice type for `IndexType`: result of calling
>> _`canonical-slice`_ on (1), still possibly out of bounds
>> 3. valid `submdspan` slice type for the $k^{th}$ extent of `E`: (2),
>> plus anything known at compile time is known to be in bounds
>> 4.  valid `submdspan` slice for the $k^{th}$ extent of `E`: (3), plus
>> fully in bounds
>>
>> Saying "valid canonical" would incorrectly imply that something can be
>> valid but not canonical.
>>
>> Thanks for your work in implementing submdspan!
>> mfh
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20251031/7c12ef0d/attachment-0001.htm>