P1684: Better explain why mdarray is not a container

[mhoemmen]

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 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.