n4355 (arrays with polymorphic layout)

[Jeremy Maitin-Shepard]

I very much like the generality with which this proposal considers the problem of multi-dimensional arrays.  It is obviously not really a complete proposal in itself, but it is particularly valuable in pointing out the issues that are not really addressed by n4346, and which are really quite critical to consider before standardizing anything.

Even though it is not a complete proposal, I do have some particular comments on it, that I'd be interested in discussing with other members of this forum:

- Something called shared_array ought to be fully general like shared_ptr, in that it can be constructed from an arbitrary memory pointer and deleter (possibly directly from a shared_ptr, and using an actual shared_ptr as the internal representation).  A constructor or free function for actually allocating an array based on a supplied or default constructor is of course very necessary as well, but that should just be a convenience interface on top of the primary (pointer, deleter) interface.

- Something called weak_array ought to behave like weak_ptr for consistency.  In particular the data should not be accessible directly, only by first calling lock and getting a shared_array.  This type would be used only when the user actually needs the safety and semantics implied by weak_ptr.  There should be a separate array_view type that just uses a raw pointer, and can be implicitly constructed from a shared_array, when the user knows the underlying memory will stay valid.  Trying to use weak_array for both purposes seems like a bad idea.

- While the generic layout support is a very interesting direction, I worry that it may be too opaque/high-level to actually be of use.  It seems that virtually every operation on an multi-dimensional array, e.g. subscripting, slicing, transposing/permuting dimensions, efficient iteration, would have to be implemented separately for each layout type. Certainly if all operations are implemented for all layout types, the result is very useful to users, but this doesn't really scale: if I want to add a new operation, I have to implement it for each layout type, and if I want to add a new layout type, I need to also implement all of the operations that I want to use.  Potentially this level of generality is just too much, and it makes sense to restrict to only strided layouts (and exclude things like tiled layouts), with possibly some additional information known at compile time (e.g. that it is in fact a C or Fortran layout).  This is a sufficiently rich abstraction that it is possible in many cases to write a generic implementation.