1. Motivation
[P0009r18] proposed
, which was approved for C++23.
It comes with the utility class template
to describe the integral extents of a multidimensional index space.
Practically,
models an array of integrals, where some of the values can be specified at compile-time.
However,
behaves very little like an array.
A notable missing feature are structured bindings, which would come in handy if the extents of the individual dimensions need to be extracted:
Before | After |
---|---|
|
|
Comparing before and after, the usability gain with structured bindings alone is marginal, but it allows us to use descriptive names for the extents to improve readability.
The proposed feature is increasingly useful when structured bindings can introduce a pack, as proposed in [P1061R4] and shown below:
With P1061 |
---|
|
In this example, we trade readability for generality.
Destructuring the extents into a pack allows us to expand the extents again into a series of
views,
which we can turn into the index space for
using a
.
Notice, that the implementation is also rank agnostic,
and for
(
's default) iterates contiguously through memory.
2. Design space
2.1. Handling static extents
When destructuring
we can deal with the compile-time/static extents in two ways:
-
Option A: Demote the compile-time/static extents to runtime values.
-
Option B: Retain the compile-time nature using e.g.
.std :: integral_constant
Option A is arguably simpler and may be less surprising.
The structured bindings just represent what the
member function would return.
Option B retains the compile-time nature of static extents at the cost of imposing a mix of integers and
upon users.
Regarding optimization potential, option A should rarely be a problem since structured bindings refer to a concrete instance of
in scope,
which is thus visible to the compiler.
Using constant propagation, the compiler can likely determine the compile-time value that the structured bindings refer to.
In the provided example below, g++ 12.2 successfully unrolls the nested loops and transforms them into vector instructions.
It’s worthwhile to point out that
has a non-explicit conversion operator to its
,
so it will be demoted automatically to a runtime value where needed (e.g. in all examples above).
2.2. Modification
Modifications of the values stored inside a
should not be allowed,
since it is neither possible in case of a static extent
nor does it follow the design of
, which returns by value.
3. Implementation Option A (demote static extents to runtime values)
One possible implementation is to use the tuple interface and delegate to
:
An example of such an implementation using the Kokkos reference implementation ofnamespace std { template < size_t I , typename IndexType , size_t ... Extents > constexpr IndexType get ( const extents < IndexType , Extents ... >& e ) noexcept { return e . extent ( I ); } } template < typename IndexType , std :: size_t ... Extents > struct std :: tuple_size < std :: extents < IndexType , Extents ... >> : std :: integral_constant < std :: size_t , sizeof ...( Extents ) > {}; template < std :: size_t I , typename IndexType , std :: size_t ... Extents > struct std :: tuple_element < I , std :: extents < IndexType , Extents ... >> { using type = IndexType ; };
std :: mdspan
on Godbolt is provided here: https://godbolt.org/z/zo5Wb6TMG.
4. Implementation Option B (retaining static extents)
One possible implementation is to use the tuple interface and query the extents type whether a specific extent is static or not.
Depending on this information, either the runtime extent via
or a
of the appropriate index type and static extent is returned:
namespace std { template < size_t I , typename IndexType , size_t ... Extents > constexpr auto get ( const extents < IndexType , Extents ... >& e ) noexcept { if constexpr ( extents < IndexType , Extents ... >:: static_extent ( I ) == dynamic_extent ) return e . extent ( I ); else return integral_constant < IndexType , static_cast < IndexType > ( extents < IndexType , Extents ... >:: static_extent ( I )) > {}; } } template < typename IndexType , std :: size_t ... Extents > struct std :: tuple_size < std :: extents < IndexType , Extents ... >> : std :: integral_constant < std :: size_t , sizeof ...( Extents ) > {}; template < std :: size_t I , typename IndexType , std :: size_t ... Extents > struct std :: tuple_element < I , std :: extents < IndexType , Extents ... >> { using type = decltype ( std :: get < I > ( std :: extents < IndexType , Extents ... > {})); };
An example of such an implementation using the Kokkos reference implementation of
on Godbolt is provided here: https://godbolt.org/z/841PeWM18.
5. Polls
The author would like to seek guidance on whether structured bindings for
are perceived as useful and
whether to continue with this proposal.
And if yes, whether implementation Option A or Option B is preferred.
6. Wording
TODO
6.1. Feature-test macro
Add the following macro definition to 17.3.2 [version.syn], Header
synopsis, with the value selected by the editor to reflect the date of adoption of this paper:
#define __cpp_lib_extents_structured_bindings 20XXXXL // also in <mdspan>
7. Acknowledgements
I would like to thank Mark Hoemmen and Christan Trott for encouraging me to write this proposal, Mark Hoemmen for suggesting implementation B, and Michael Hava for reviewing.