Title
Specializations of `layout_transpose` do not meet the layout mapping policy requirements
Status
new
Section
[linalg.transp.layout.transpose] [mdspan.layout.policy.reqmts]
Submitter
Charles Hussong

Created on 2026-05-19.00:00:00 last changed 6 days ago

Messages

Date: 2026-06-20.12:17:28

Proposed resolution:

This wording is relative to N5046.

  1. Modify [mdspan.layout.policy.reqmts] as indicated:

    -1- A type `MP` meets the layout mapping policy requirements if there exists at least one rank index `r` such that, for a type `E` of rank `r` that is a specialization of `extents`, MP::mapping<E> is valid and denotes a type `X` that meets the layout mapping requirements ([mdspan.layout.reqmts]), and for which the qualified-id `X::layout_type` is valid and denotes the type `MP` and the qualified-id `X::extents_type` denotes `E`.

Date: 2026-06-15.00:00:00

[ 2026-06-16, Mark Hoemmen comments and provides improved wording ]

I don't like this. A layout is supposed to be a "function" from extents type to layout mapping type. We messed up with accessors; we should have done the same thing to make an "accessor policy" that is a function from element type to accessor type. (That would have solved the "given an mdspan with nonconst element type, how do I get an mdspan viewing the same elements with const element type?" problem.)

It might make sense to let layouts restrict the set of valid ranks. That would fix the issue without requiring a redesign of `transposed`. I suggest the following fix.

Date: 2026-06-20.12:17:28

[linalg.transp.layout.transpose] bullet (3.2) specifies a Mandate that the rank of the extents used with this layout must equal 2. However, the layout mapping policy requirements at [mdspan.layout.policy.reqmts] are worded in the following way:

A type `MP` meets the layout mapping policy requirements if for a type `E` that is a specialization of `extents`, MP::mapping<E> is valid and denotes a type `X` that meets the layout mapping requirements ([mdspan.layout.reqmts]), […]

We interpret this to mean that in order for `MP` to be a layout mapping policy, it must be possible to instantiate MP::mapping<E> for any extents `E`, with no additional mandates. Since `layout_transpose` does not satisfy this, specializations of it do not meet the layout mapping policy, which contradicts [linalg.transp.intro] p1, and [linalg.transp.layout.transpose] p1, and makes any `mdspan` using `layout_transpose` (including the return type of `transposed`([linalg.transp.transposed])) ill-formed.

I think the most straightforward solution to this would be to change the layout mapping policy requirements:

A type `MP` meets the layout mapping policy requirements if for aat least one type `E` that is a specialization of `extents`, MP::mapping<E> is valid and denotes a type `X` that meets the layout mapping requirements […]

Unfortunately this is a much looser requirement, but I'm not sure how else to accommodate a sensible definition of `layout_transpose` within the stricter version.

Considered alternatives:

`layout_transpose` could be redefined to either always transpose the first two or last two ranks. I did not submit this because it could easily get confusing for users (was it the first two or the last two, or maybe something else entirely?) and there's no sensible behavior for rank 1.

Another option would be to replace the notion of "meet the layout mapping policy requirements" with "meet the layout mapping policy requirements for extents `E`". My understanding is that this goes against the spirit of the design where the layout mapping policy is not templated on the specific extents, while the layout mapping is.

This wording is relative to N5046.

  1. Modify [mdspan.layout.policy.reqmts] as indicated:

    -1- A type `MP` meets the layout mapping policy requirements if for aat least one type `E` that is a specialization of `extents`, MP::mapping<E> is valid and denotes a type `X` that meets the layout mapping requirements ([mdspan.layout.reqmts]), and for which the qualified-id `X::layout_type` is valid and denotes the type `MP` and the qualified-id `X::extents_type` denotes `E`.

History
Date User Action Args
2026-06-20 12:17:28adminsetmessages: + msg16487
2026-05-25 15:46:18adminsetmessages: + msg16327
2026-05-19 00:00:00admincreate