The review expressed a preference for the current "container adapter" (but see below) design. Those not preferring that design expressed the concern documented as #15. Regardless, participants wanted us to explain better in the paper the trade-offs between the current "container adapter" (but see below) design, and an mdarray-as-container design. Here is a draft of that explanation.
(R0 design had a "container policy" to do automatic switching. R1 went away from that.)
Benefits of mdarray-as-container design
Allocator directly visible, instead of hidden in Container
No need to specify Container type requirements
Drawbacks of mdarray-as-container design
Container design calls for two different array types ("static_mdarray" vs "dynamic_mdarray") to handle all-static-extents vs. some-dynamic-extents cases, just like array vs. vector
But, 2 types is not consistent with mdspan design, which uses a single class for both cases
One class for both cases is consistent with other libraries, like Kokkos::View and Eigen
(but contrast with Boost uBLAS)
Benefits of "container adapter" design
Allocator not part of type if it doesn't need to be
Cost of move is exposed as Container, not implicit in Extents
(array move is more expensive than vector move)
Users can customize allocation and access (as with mdspan's Accessor)
One reviewer pointed out that it's not necessarily accurate to call the current design a "container adapter." This is because the dynamic or static nature of extents are separate from what's contained. The properties are customizable, not like stack or queue. This is more of an issue for wording than for design, but it's still something to keep in mind.
This comes from 1684R2 LEWG review on 2022/04/19.
The review expressed a preference for the current "container adapter" (but see below) design. Those not preferring that design expressed the concern documented as #15. Regardless, participants wanted us to explain better in the paper the trade-offs between the current "container adapter" (but see below) design, and an
mdarray-as-container design. Here is a draft of that explanation.(R0 design had a "container policy" to do automatic switching. R1 went away from that.)
Benefits of
mdarray-as-container designDrawbacks of
mdarray-as-container designstatic_mdarray" vs "dynamic_mdarray") to handle all-static-extents vs. some-dynamic-extents cases, just likearrayvs.vectormdspandesign, which uses a single class for both casesKokkos::Viewand EigenBenefits of "container adapter" design
arraymove is more expensive thanvectormove)mdspan's Accessor)One reviewer pointed out that it's not necessarily accurate to call the current design a "container adapter." This is because the dynamic or static nature of extents are separate from what's contained. The properties are customizable, not like
stackorqueue. This is more of an issue for wording than for design, but it's still something to keep in mind.