This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4582. Specializations of layout_transpose do not meet the layout mapping policy requirements

Section: 29.9.10.3 [linalg.transp.layout.transpose], 23.7.3.4.3 [mdspan.layout.policy.reqmts] Status: New Submitter: Charles Hussong Opened: 2026-05-19 Last modified: 2026-06-20

Priority: Not Prioritized

View all issues with New status.

Discussion:

29.9.10.3 [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 23.7.3.4.3 [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 (23.7.3.4.2 [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 29.9.10.1 [linalg.transp.intro] p1, and 29.9.10.3 [linalg.transp.layout.transpose] p1, and makes any mdspan using layout_transpose (including the return type of transposed(29.9.10.4 [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.

[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.

Proposed resolution:

This wording is relative to N5046.

1. Modify 23.7.3.4.3 [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 (23.7.3.4.2 [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.