"The SliceSpecifier template argument(s)" in (2) should be SliceSpecifiers (typo).
Bikeshed: strided_index_range is obviously not a range in the sense of the "ranges" library.
Does src-indices need to be constexpr? In general, do these functions need to be constexpr?
submdspan_extents:
Should the constraints be mandates instead?
Typo: (2) says src.extents(), should be src_exts.extents()
Why the difference between constraints and mandates? What's the goal? Note that the Mandates would subsume ... we could probably get rid of the Constraints there.
Rather than requiring integral_constant, should we consider requiring it to be a "core constant literal type"? hana like? Expect some off-line comments to clarify this request.
submdspan_mapping
Do we run into the problems that CPOs solve? Specifically making it hard to debug where exactly it landed? -- Users generally wouldn't call these functions, so users don't have to do the ADL dance. However, if this were a hidden friend, then you would only be able to call these by ADL. Some additional benefits. We could explore this.
Use the state of the art for customization points; maybe tag_invoke if it is considered the state of the art.
Specializations of submdspan_mapping
(6) is missing a close angle bracket (array<SubExtents::index_type, SubExtents::rank()>).
sub_map was not introduced before (3.1) (the Mandates that starts with is_same_v and checks the extents with submdspan_extents result). (sub_map should be something like declval<decltype(submdspan_mapping(...))>.)
submdspan
(Effects rely on CTAD, but that's OK.)
Any design questions
Customization point design?
integral_constant?
Convertibility to tuple
stride design
IL: Niebloids are used in ranges, tag_invoke is used for sender/receivers. I would suggest looking at the paper by Barry (https://wg21.link/P2279) and applying a more "modern-style" CP mechanism.
submdspan Kona 2022/11/11 feedback
"The
SliceSpecifier
template argument(s)" in (2) should beSliceSpecifiers
(typo).Bikeshed:
strided_index_range
is obviously not a range in the sense of the "ranges" library.Does
src-indices
need to beconstexpr
? In general, do these functions need to beconstexpr
?submdspan_extents
:Should the constraints be mandates instead?
Typo: (2) says
src.extents()
, should besrc_exts.extents()
Why the difference between constraints and mandates? What's the goal? Note that the Mandates would subsume ... we could probably get rid of the Constraints there.
Rather than requiring integral_constant, should we consider requiring it to be a "core constant literal type"? hana like? Expect some off-line comments to clarify this request.
submdspan_mapping
Do we run into the problems that CPOs solve? Specifically making it hard to debug where exactly it landed? -- Users generally wouldn't call these functions, so users don't have to do the ADL dance. However, if this were a hidden friend, then you would only be able to call these by ADL. Some additional benefits. We could explore this.
Use the state of the art for customization points; maybe
tag_invoke
if it is considered the state of the art.Specializations of
submdspan_mapping
(6) is missing a close angle bracket (
array<SubExtents::index_type, SubExtents::rank()>
).sub_map
was not introduced before (3.1) (the Mandates that starts withis_same_v
and checks the extents withsubmdspan_extents
result). (sub_map
should be something likedeclval<decltype(submdspan_mapping(...))>
.)submdspan
(Effects rely on CTAD, but that's OK.)
Any design questions
integral_constant
?