P3663R3 Future-proof `submdspan_mapping` #8526

eisenwave · 2025-11-15T15:36:06Z

Fixes #8464
Fixes NB PL-009, US 66-117 (C++26 CD).

Also fixes cplusplus/papers#2292
Also fixes https://github.com/cplusplus/nbballot/issues/695
Also fixes https://github.com/cplusplus/nbballot/issues/818

Somehow relates to https://github.com/cplusplus/nbballot/issues/815 but I'm not sure how

Fixes NB PL-009, US 66-117 (C++26 CD).

jwakely · 2025-11-15T16:50:31Z

Somehow relates to cplusplus/nbballot#815 but I'm not sure how

That comment is asking to rename two things, one of which was added by this paper. This commit doesn't address that comment.

mhoemmen · 2025-11-17T15:38:13Z

source/containers.tex

+  %FIXME: this is in adifferent subclause but the paper has no title for it
+  template<class IndexType, size_t... Extents, class... Slices>
+    constexpr auto submdspan_canonicalize_slices(const extents<IndexType, Extents...>& src,
+                                                 Slices... slices);
+
  template<class IndexType, size_t... Extents, class... SliceSpecifiers>
    constexpr auto submdspan_extents(const extents<IndexType, Extents...>&, SliceSpecifiers...);


Suggested change

%FIXME: this is in adifferent subclause but the paper has no title for it

template<class IndexType, size_t... Extents, class... Slices>

constexpr auto submdspan_canonicalize_slices(const extents<IndexType, Extents...>& src,

Slices... slices);

template<class IndexType, size_t... Extents, class... SliceSpecifiers>

constexpr auto submdspan_extents(const extents<IndexType, Extents...>&, SliceSpecifiers...);

template<class IndexType, size_t... Extents, class... SliceSpecifiers>

constexpr auto submdspan_extents(const extents<IndexType, Extents...>&, SliceSpecifiers...);

// \ref{mdspan.sub.canonical}, \tcode{submdspan} slice canonicalization

template<class IndexType, size_t... Extents, class... Slices>

constexpr auto submdspan_canonicalize_slices(const extents<IndexType, Extents...>& src,

Slices... slices);

mhoemmen · 2025-11-17T15:38:26Z

source/containers.tex

  struct full_extent_t { explicit full_extent_t() = default; };
  inline constexpr full_extent_t full_extent{};

+  %FIXME: this is in adifferent subclause but the paper has no title for it


Please see suggestion below; thanks!

mhoemmen · 2025-11-17T15:43:59Z

source/containers.tex

+%FIXME: WEIRD: the paper inconsistently uses math font and code font for the "S"
+%       that we are defining.
+%       To my understanding, we should aim to use code fonts for types,
+%       so this math font $S$ should be replaced.


P2630 and the status quo both use math fonts for both slice types and slices; see [mdspan.sub.overview] 2.3 and 2.4. P2630 predates pack indexing, so it uses math-font $S_k$ and $s_k$ in order to avoid less convenient code-font expressions. P3663 adopted pack indexing in its reformulation of submdspan, so it removed the $k$ subscripting but somewhat retained the habit of math-font slices.

All this is saying that (a) math font has a precedent (whether or not you think it's "WEIRD" ; - ) ), and (b) we would welcome more consistency, whatever that might mean in terms of fonts.

mhoemmen · 2025-11-17T15:46:02Z

source/containers.tex

+%FIXME: the way I marked up this definition is almost certainly not the way it should be done
+\defnx{\tcode{submdspan} slide type for \tcode{IndexType}}{\tcode{submdspan}!slice type}


Not sure why you added extra text here. The phrase of power is "submdspan slice type for IndexType." We did not define "submdspan slice type" by itself.

mhoemmen · 2025-11-17T15:47:14Z

source/containers.tex

+  %FIXME: Oxford comma
+  \tcode{$S$::extent_type} and


Oxford comma is good, but editorial. (Just fix it if you see it.)

Suggested change

%FIXME: Oxford comma

\tcode{$S$::extent_type} and

\tcode{$S$::extent_type}, and

mhoemmen · 2025-11-17T15:48:50Z

source/containers.tex

+\pnum
+Given a signed or unsigned integer type \tcode{IndexType},
+a type $S$ is a
+\defnx{canonical \tcode{submdspan} index type for \tcode{IndexType}}{\tcode{submdspan}!canonical index type}


Not sure why you're adding extra text here. The phrase of power is "canonical submdspan index type for IndexType." The words "for IndexType" are not optional.

mhoemmen · 2025-11-17T15:49:14Z

source/containers.tex

+\pnum
+Given a signed or unsigned integer type \tcode{IndexType},
+a type $S$ is a
+\defnx{canonical \tcode{submdspan} slice type for \tcode{IndexType}}{\tcode{submdspan}!canonical slice type}


Again, not sure why you're adding extra text here.

mhoemmen · 2025-11-17T15:50:09Z

source/containers.tex

+Given an object \tcode{e} of type \tcode{E} that is a specialization of \tcode{extents}, and
+an object \tcode{s} of type \tcode{S}
+that is a canonical \tcode{submdspan} slice type for \tcode{E::index_type},
+the \defnx{\tcode{submdspan} slice range of \tcode{s} for the $k^\text{th}$ extent of \tcode{E}}{\tcode{submdspan}!slice range}


Again, not sure what the extra text at the end is for.

mhoemmen · 2025-11-17T15:51:03Z

source/containers.tex

+%FIXME: the trailing comma here makes no grammatical sense
+\defnx{valid \tcode{submdspan} slice type for the $k^\text{th}$ extent of \tcode{E}}{\tcode{submdspan}!valid slice type},


Please feel welcome to remove the trailing comma : - )

Again, not sure what the extra text at the end of this line is for.

mhoemmen · 2025-11-17T15:51:46Z

source/containers.tex

+\defnx{valid \tcode{submdspan} slice type for the $k^\text{th}$ extent of \tcode{E}}{\tcode{submdspan}!valid slice type},
+if \tcode{S} is a canonical slice type for \tcode{E::index_type}, and
+for
+%FIXME: this is weird ... what is "x"?


"for $x$ equal to E::static_extent($k$)"

mhoemmen · 2025-11-17T15:52:23Z

source/containers.tex

+if \tcode{S} is a canonical slice type for \tcode{E::index_type}, and
+for
+%FIXME: this is weird ... what is "x"?
+%Maybe say "for a value x"?


It's not "a value," it's the value E::static_extent($k$).

mhoemmen · 2025-11-17T16:09:04Z

source/containers.tex

+%FIXME: what is this section supposed to be called?
+\rSec4[mdspan.sub.canonical]{\tcode{submdspan_extents} something something}


Suggested change

%FIXME: what is this section supposed to be called?

\rSec4[mdspan.sub.canonical]{\tcode{submdspan_extents} something something}

\rSec4[mdspan.sub.canonical]{\tcode{submdspan} slice canonicalization}

mhoemmen · 2025-11-17T16:09:33Z

source/containers.tex

-\tcode{\exposid{first_}<IndexType, $k$>(slices...)} \tcode{+}
-\tcode{indices[\placeholder{map-rank}[$k$]]}.
+  \tcode{decltype(canonical-slice<IndexType>(slices...[k]))}
+  is a valid submdspan slice type for the $k^\text{th}$ extent of


Suggested change

is a valid submdspan slice type for the $k^\text{th}$ extent of

is a valid `submdspan` slice type for the $k^\text{th}$ extent of

mhoemmen · 2025-11-17T17:32:32Z

source/containers.tex

+%FIXME: The paper cites "equals Extents::rank()" as the pre-existing wording.
+%Investigate whether the change is still okay (which only affects the left side).
+\tcode{sizeof...(SliceSpecifiers)} equals \tcode{sizeof...(Extents)}.


Your suggested change is correct; thank you!

Suggested change

%FIXME: The paper cites "equals Extents::rank()" as the pre-existing wording.

%Investigate whether the change is still okay (which only affects the left side).

\tcode{sizeof...(SliceSpecifiers)} equals \tcode{sizeof...(Extents)}.

\tcode{sizeof...(SliceSpecifiers)} equals \tcode{sizeof...(Extents)}.

mhoemmen · 2025-11-17T17:47:29Z

source/containers.tex

-\tcode{SubExtents::rank()} equals the number of $k$ such that
-$S_k$ does not model \tcode{\libconcept{convertible_to}<IndexType>}; and
+\tcode{SubExtents::rank()} equals
+\tcode{\exposid{MAP_RANK}(slices, Extents::rank())}; and


I think we have the same issue as above here with Extents::rank(). The existing text below says "for each rank index $k$ of \tcode{Extents}", so it may pay to introduce a name for the extents type. For example, we could change paragraph 1 like this

Let E denote extents<IndexType, Extents...>, and let slices be the pack ....

and then use E throughout, e.g., in paragraph 2.

That being said, perhaps it's better just to merge the text as-is and then file an LWG issue with the above as a proposed fix. What do you think?

mhoemmen · 2025-11-17T17:58:18Z

source/containers.tex

+  %FIXME: IMPORTANT: There is a closing parenthesis in the inserted wording,
+  %but no opening parenthesis.
+  %Did we mean to do: (1 + ...) / ...
+  %               or: (1 + ... / ...)
+  \tcode{1 + ($\Sigma_k$::extent_type::value - 1) / $\Sigma_k$::stride_type::value},


Thanks for pointing this out! We meant to do 1 + ((extent - 1) / stride). The plus 1 goes on the very outside and is not part of the division.

Suggested change

%FIXME: IMPORTANT: There is a closing parenthesis in the inserted wording,

%but no opening parenthesis.

%Did we mean to do: (1 + ...) / ...

% or: (1 + ... / ...)

\tcode{1 + ($\Sigma_k$::extent_type::value - 1) / $\Sigma_k$::stride_type::value},

\tcode{1 + ($\Sigma_k$::extent_type::value - 1) / $\Sigma_k$::stride_type::value},

mhoemmen · 2025-11-17T18:02:44Z

source/containers.tex

+%FIXME: is ISO going to like a bullet ending in a colon?
+the following expression is well-formed and has the specified semantics:


%FIXME: is ISO going to like a bullet ending in a colon?

I don't know; does it? ; - )

Suggested change

%FIXME: is ISO going to like a bullet ending in a colon?

the following expression is well-formed and has the specified semantics:

the following expression is well-formed and has the specified semantics.

mhoemmen · 2025-11-17T18:03:15Z

source/containers.tex

+      %FIXME: the comma before "otherwise" seems wrong
+      \tcode{i...[MAP_RANK(valid_slices,$\rho$)]}, otherwise.


Suggested change

%FIXME: the comma before "otherwise" seems wrong

\tcode{i...[MAP_RANK(valid_slices,$\rho$)]}, otherwise.

\tcode{i...[MAP_RANK(valid_slices,$\rho$)]} otherwise.

mhoemmen · 2025-11-17T18:06:33Z

source/containers.tex

+%FIXME: this doesn't make any sense.
+%How can an lvalue like "s" be the specialization of a type?
+if \tcode{s} is a specialization of \tcode{strided_slice} and


Suggested change

%FIXME: this doesn't make any sense.

%How can an lvalue like "s" be the specialization of a type?

if \tcode{s} is a specialization of \tcode{strided_slice} and

if the type of \tcode{s} is a specialization of \tcode{strided_slice} and

mhoemmen · 2025-11-17T18:07:45Z

source/containers.tex

+%FIXME: comma?
+where \tcode{s} is \tcode{slices...[$k$]};


There is a lot of punctuation in 6.1, so a semicolon felt right. It's fine if you would like to use a comma, though. That would probably call for 6.2 to become "stride($k$) otherwise."

mhoemmen · 2025-11-17T18:21:53Z

source/containers.tex

 if
  \begin{itemize}
  \item
+  %FIXME: drive-by fix this broken parenthesis,


I don't see what you're talking about here.

mhoemmen · 2025-11-17T18:22:25Z

source/containers.tex

 Let \tcode{index_type} be \tcode{typename Extents::index_type}.

+\pnum
+Let \tcode{slices} be the pack introduced by the following declaration:


Please see your above comment about ISO maybe not liking the colon here; thanks!

mhoemmen

Thanks for doing the wording for this! : - )

P3663R3 Future-proof submdspan_mapping

4f95712

Fixes NB PL-009, US 66-117 (C++26 CD).

eisenwave requested a review from mhoemmen November 15, 2025 15:36

eisenwave added this to the post-2025-11 milestone Nov 15, 2025

mhoemmen reviewed Nov 17, 2025

View reviewed changes

mhoemmen suggested changes Nov 17, 2025

View reviewed changes

		%FIXME: the way I marked up this definition is almost certainly not the way it should be done
		\defnx{\tcode{submdspan} slide type for \tcode{IndexType}}{\tcode{submdspan}!slice type}

	%FIXME: Oxford comma
	\tcode{$S$::extent_type} and
	\tcode{$S$::extent_type}, and

		%FIXME: the trailing comma here makes no grammatical sense
		\defnx{valid \tcode{submdspan} slice type for the $k^\text{th}$ extent of \tcode{E}}{\tcode{submdspan}!valid slice type},

		%FIXME: what is this section supposed to be called?
		\rSec4[mdspan.sub.canonical]{\tcode{submdspan_extents} something something}

	is a valid submdspan slice type for the $k^\text{th}$ extent of
	is a valid `submdspan` slice type for the $k^\text{th}$ extent of

		%FIXME: is ISO going to like a bullet ending in a colon?
		the following expression is well-formed and has the specified semantics:

		%FIXME: the comma before "otherwise" seems wrong
		\tcode{i...[MAP_RANK(valid_slices,$\rho$)]}, otherwise.

P3663R3 Future-proof submdspan_mapping #8526

Are you sure you want to change the base?

P3663R3 Future-proof submdspan_mapping #8526

Uh oh!

Conversation

eisenwave commented Nov 15, 2025

Uh oh!

jwakely commented Nov 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhoemmen Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhoemmen left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

P3663R3 Future-proof `submdspan_mapping` #8526

P3663R3 Future-proof `submdspan_mapping` #8526

mhoemmen Nov 17, 2025 •

edited

Loading