Issaquah (Feb 2023) P1684R4 LEWG feedback

Issaquah (Feb 2023) P1684R4 LEWG feedback

Extraction of container from the mdarray

LEWG audience asked about "extraction" of the container from the mdarray. One application would be reinterpreting the data without reallocation, by moving the container out of one mdarray, and into a different mdarray with a different layout and/or extents.

Our objection to this was and is that if the mdarray had all static extents, then it would have no way to "zero out" the extents after extraction. The resulting mdarray would have a nonempty multidimensional index space domain, but no valid elements. (For example, consider an mdarray with extents<int, 2, 3, 4> but std::vector container. Extraction of the storage would leave the mdarray with no storage, but with a layout mapping that would accept any multidimensional index in extents<int, 2, 3, 4>.)

The counter is that mdarray already has a move constructor and a move assignment operator. What would happen to the moved-from object in these cases? Some LEWG members suggested constraining these operators on whether rank_dynamic() != 0. Regardless, the "extracted-from" state is the same as the "moved-from" state; the problems are the same for both.

Custom containers add another aspect to this issue. std::vector carefully specifies its moved-from state, but a custom container could have a moved-from state with invalid storage and an incorrectly preserved size().

Another question is whether the move constructor might need to allocate, in which case it might throw and thus should not be marked noexcept.

Are we concerned that a matrix of bool would default to std::vector<bool>?

This would actually affect the default accessor type that to_mdspan would use. We couldn't use default_accessor<bool> in this case, because std::vector<bool> doesn't actually store an array of bool. What we would need is some kind of "container_accessor" that perhaps defaults to default_accessor<element_type> if the container's reference and pointer types are suitable.

Other points

• Feature test macro?

• Format facilities interaction?

  • It would make sense for us to do that through mdspan first, in a separate paper.

No source files, tests, or implementation entry points are named. Start by reviewing the P1684R4 design and the listed LEWG questions about extraction, moved-from states, vector accessors, feature-test macros, and formatting. Done requires an agreed resolution for the design questions, but the issue does not define one.