Better mdspan's CTAD

• • Abstract
  • Revision history
  • Discussion
  • Design
  • Proposed change
  • References

Abstract

This paper makes span and mdspan' CTAD integral_constant-aware to deduce more efficient types.

Revision history

R0

Initial revision.

R1

1. Changed the comma in CTAD of span(It, EndOrSize), which is part of the wording, to green.
2. Initialized the maybe-static-ext's specialization with {T::value} to prevent conversions from negative values.
3. Aligned with the latest working draft.

Discussion

Currently, mdspan's most common pointer-indices CTAD have the following definitions:

  template<class ElementType, class... Integrals>
    requires((is_convertible_v<Integrals, size_t> && ...) && sizeof...(Integrals) > 0)
    explicit mdspan(ElementType*, Integrals...)
      -> mdspan<ElementType, dextents<size_t, sizeof...(Integrals)>>;

Since the Extents template parameter of mdspan is explicitly specified as dextents, the deduced type always has dynamic extent, even if we pass a compile-time constant:

  mdspan ms (p, 3, 4, 5); // mdspan<int, extents<size_t, dynamic_extent, dynamic_extent, dynamic_extent>>
  mdspan ms2(p, 3, integral_constant<size_t, 4>{}, 5);                              // ditto
  mdspan ms3(p, integral_constant<size_t, 3>{}, 4, integral_constant<size_t, 5>{}); // ditto

This result feels wrong to me. If integral_constant represents a compile-time constant, why don't we take advantage of it and make it reflect the extent of mdspan, since we already did this with strided_slice?

The author believes that instead of setting static extents by additionally creating extents:

  mdspan ms2(p, extents<size_t, dynamic_extent, 4, dynamic_extent>(3, 5)); // mdspan<int, extents<size_t, dynamic_extent, 4, dynamic_extent>>
  mdspan ms3(p, extents<size_t, 3, dynamic_extent, 5>(4));                 // mdspan<int, extents<size_t, 3, dynamic_extent, 5>>

It would be better to automatically make the first example equivalent based on whether the argument is a compile-time constant.

This brings the following benefits:

1. It enables defining dynamic or static extents with the similar form and intuitively reflects the extent type.
2. It's less error-prone as we don't need to calculate how many dynamic_extents there are to pass in the correct number of arguments. The compiler already handle it for us.
3. It makes defining mdspan more concise, an mdspan with mixed extents now can be spelled as mdspan(c_<3>{}, 4, c_<5>{}) (benefit from P2781 std::constexpr_v).

Design

span's CTAD

The paper also applies to span' CTAD for consistency. In other words, span(p, c_<5>{}) will be deduced as span<int, 5>. The author doesn't think this is a big issue as it's relative intuitive and generally users don't often write this way.

mdspan's CTAD

Given that P2630 std::submdspan already introduced integral-constant-like for checking integral_constant-like type, this paper reuses it to detect whether mdspan's arguments are a compile-time constant. This also applies to extents.

Proposed change

This wording is relative to N4971.

References