libstdc++: potential bug in specification of layouts.

[Jonathan Wakely]

On Tue, 13 May 2025 at 10:54, Luc Grosheintz wrote:
>
> This email chain continues a discussion about potential bugs in the
> specification that was started here:
> https://gcc.gnu.org/pipermail/libstdc++/2025-May/061350.html
>
> For notational convenience, I'll write `layout_left` as shorthand for
> `layout_left::mapping`, e.g. layout_left::required_span_size, refers to
> layout_left::mapping<Extents>::required_span_size.

Thanks for writing these up, Luc.

Once the discussion concludes here you can submit one or more issues
to the LWG chair (which is, er, me) as documented at
https://cplusplus.github.io/LWG/lwg-active.html#submit_issue


> 1. operator==
>
> The observation is that for rank0 and rank1, two mappings, one of type
> layout_left<Extents> and the other layout_right<OExtents>, the
> operator== is ambiguous if `Extents == OExtents`; but not if the extents
> are convertible (because the convertability is only in one direction).
>
> Godbolt: https://godbolt.org/z/35TbMnc1e
>
> Resolution: It's not clear to me what to propose. Likely, something that
> fixes the ambiguity issue to allow comparing all rank 0 and rank 1
> instances of layout_left and layout_right. Help would be most welcome:
> either by collaboratively working on the proposed change; or if someone
> wants to take over completely that would also work.

N.B. it's not necessary to have a resolution when reporting an issue.
Generally issues will get resolved sooner if there's a proposed
resolution (even if it's a bad one, because that might nerdsnipe
somebody into writing a better one!
https://meta.wikimedia.org/wiki/Cunningham%27s_Law applies here).


>
>
> 2. Missing `noexcept` in layout_left.
>
> The specification (N4950 and as published on `eel.is`) consistently
> doesn't mention `noexcept` in both the Overview and Constructors
> sections for `layout_left(layout_stride)`.
>
> https://eel.is/c++draft/mdspan.layout.left#overview-1
> https://eel.is/c++draft/mdspan.layout.left#lib:layout_left::mapping,constructor____
>
> Resolution: I suggest that I file an issue to add `noexcept`
> consistently. Can this be considered an editorial issue?

Since it's *consistently* missing, I don't think we can consider it
editorial. What is in the standard matches what was approved by the
committee.

And this seems to be an intentional application of the "Lakos rule"
which says that functions with narrow contracts (i.e. with
preconditions) should not be noexcept. We can strengthen that and add
noexcept in the implementation, if we know that our implementation
never throws exceptions as a result of precondition violations (and
will never do so in future, e.g. if we were to start using C++26
contracts to check preconditions, which would mean the constructors
could throw if the user provides a throwing contract violation
handler).


>
> 3. Inconsistency about `constexpr` in layout_right::required_span_size.
>
> The section Overview specifies that `required_span_size` must be
> constexpr. In the section Observers this keyword is missing.
>
> I believe this is considered an editorial issue; and I can fix it by
> submitting a PR to the text of the standard.
>
> https://eel.is/c++draft/mdspan.layout.right#overview-1
> https://eel.is/c++draft/mdspan.layout.right.obs#lib:required_span_size,layout_right::mapping
>
> Resolution: I suggest that I file an editorial issue.

I see you already filed that, thanks.

>
> 4. Inconsistency about `noexcept` in `layout_left::stride`.
>
> The section Overview mentions it's `noexcept` but the section Observers
> doesn't. Again, I think this is an editorial issue.
>
> https://eel.is/c++draft/mdspan.layout.left#overview-1
> https://eel.is/c++draft/mdspan.layout.left.obs#lib:stride,layout_left::mapping
>
> Resolution: I suggest that I file an editorial issue.

That was recently fixed editorially:
https://github.com/cplusplus/draft/pull/7831
The unofficial HTML draft is out of date.

>
>
> 5. At Rank 0 layout_stride is untypically convertible.
>
> Commonly, two layouts are considered convertible, if the underlying
> extent_types are convertible, e.g.
>
> https://eel.is/c++draft/mdspan.layout.left.cons#lib:layout_left::mapping,constructor_
> https://eel.is/c++draft/mdspan.layout.left.cons#lib:layout_left::mapping,constructor__
> https://eel.is/c++draft/mdspan.layout.right.cons#lib:layout_right::mapping,constructor_
> https://eel.is/c++draft/mdspan.layout.right.cons#lib:layout_right::mapping,constructor__
> https://eel.is/c++draft/mdspan.layout.stride.cons#9
>
> However, for the two ctors `layout_left(layout_stride)` and
> `layout_right(layout_stride)`, the condition is `rank > 0`. Therefore,
>
>      using E1 = std::extents<int>;
>      using E2 = std::extents<unsigned int>;
>
>      static_assert(std::is_convertible_v<
>          std::layout_stride::mapping<E2>,
>          std::layout_right::mapping<E1>
>        >);
>
> even though:
>
>      static_assert(!std::is_convertible_v<E2, E1>);
>
> https://eel.is/c++draft/mdspan.layout.left.cons#lib:layout_left::mapping,constructor____
> https://eel.is/c++draft/mdspan.layout.right.cons#lib:layout_right::mapping,constructor____
>
> Moreover, for rank 0 layout_stride can be converted to any
> specialization of layout_left or layout_right; but not to every
> specialization of `layout_stride`.
>
> Godbolt: https://godbolt.org/z/MdbvafG7n
>
> Resolution: I suggest I create an non-editorial issue to propose adding
> the convertibility criterium to the explicitness condition.
>