P2642: Fixes for changes from LWG 2024/01/31 review

Fixes for changes from LWG 2024/01/31

[mdspan.layout.leftpadded.cons]

The constexpr mapping(const extents_type& ext); constructor currently has the following precondition (paragraph 2.2).

  * [2.2]{.pnum} If `extents_type::rank()` is greater than one
    and `padding_value` does not equal `dynamic_extent`,
    then $\mathit{least\_multiple\_at\_least}($ `padding_value` $,$ `ext.extent(0)` $)$
    is representable as a value of type `index_type`.

Given this wording, the following is not a precondition violation but will still produce offsets exceeding MAX_INT.

constexpr int e1 = MAX_INT / 3;
constexpr int s1 = 2*e1;
layout_left_padded<s1>::mapping<dextents<int, 2>> map(dextents<int, 2>{e1, 2}); 

@crtrott suggests the following wording.

  * [2.2]{.pnum} If `extents_type::rank()` is greater than one
    and `padding_value` does not equal `dynamic_extent`,
    then $\mathit{least\_multiple\_at\_least}($ `padding_value` $,$ `ext.extent(0)` $)$
    times the size of the multidimensional index space `ext` divided by `ext.extent(0)`
    is representable as a value of type `index_type`.

Other

The Mandate "padding_value is representable as a value of type index_type" (without further qualifications) is wrong, because dynamic_extent is generally not representable as index_type.

index_type @_stride-rm2_@ = @_static-padding-stride_@ is an unsafe conversion when static-padding-stride is dynamic_extent and index_type is not size_t. The default member initializer shouldn't take effect in that case, but the syntax itself might still be incorrect.

Start with the [mdspan.layout.leftpadded.cons] section and its listed constructor precondition, then review the two concerns under “Other.” Done means the proposed wording and the handling of dynamic_extent conversions are resolved consistently in the paper.