P0009r8 results of San Diego review

[mhoemmen]

Per request by @hcedwar, I'm posting the link to the minutes from Saturday LWG small group P0009R8 (mdspan): http://wiki.edg.com/bin/view/Wg21sandiego2018/SanDiego2018P0009

[mhoemmen]

Retitled after consultation with @dsunder .

[dhollman]

Notes:

• AFAIK a move constructor is never QOI. There needs to be an implementation-agnostic response to std::is_move_constructible_v. We very definitely should not strike the move constructor from extents. I can't think of any analog in the standard for this sort of thing; can anyone else? If this happened, you could have one implementation where std::swap(ex1, ex2) works fine, and then in another implementation it doesn't even compile. That's not how standards work, AFAICT.
• this->extent(r) would be inconsistent with how all of the rest of the standard does things. See, e.g., span. We just want extent(r) there. (Oh, just got to the point where GR withdrew this comment, never mind)
• Compile-time matching of static extents can't be QOI for the same reason as the move constructor. is_convertible_v should be the same across implementations.
• The comment about value-initializes instead of aggregate-initializes: since dynamic_extents_ is a std::array, value-initialization doesn't do what you want for built-in types. This should be aggregate-initializes.

More comments to come...

[dhollman]

More notes:

• GR's comment that the effects clause is redundant in the constructors is incorrect AFAICT. Those clauses are needed to make the exposition-only variable meaningful in the rest of the wording. They should remain in there. (I mimicked several other uses of exposition-only variables in the standard in this respect. I think there's a comment in the bikeshed source listing what I mimicked).
• same comments as above with dynamic_extents... ctor. I'm pretty sure I did my homework on these, so if I'm wrong I'd like to see more than a passing comment as to why I'm wrong.
• I think the rank_dynamic() != 0 constraint on the dynamic_extents... constructor is unnecessary, since the is_convertible_v fold expression will be false in that case.
• I think there's a lot of confusing arising in the std::array constructor from the fact that somehow we ended up with a deduced rank_dynamic template parameter. rank_dynamic should have been non-deduced and fixed to the valuerank_dynamic(), just as in the exposition-only parameter. I don't know if this was my typo or got added later, but hopefully this clears things up.

[dhollman]

More:

• Deduction guides are not an issue; the template parameters don't participate in any of the constructors, so none of them should produce implicit deduction guides and there's no way to produce explicit deduction guides from any of the constructors since the information about the sizes of the static extents simply isn't there.
• On the use of rank_dynamic() in the type of the exposition only member—if it helps, I tried all of the alternatives discussed in the notes, and ended up with this one (I guess I didn't test MSVC...); seems like the room settled on the same thing?

On layout:

• The "defining a multidimensional index space." piece is there to indicate that references to multidimensional indices in the table that follows are part of that space. I went back and forth on how to clarify that, and landed on that phrasing.
• The last bullet before the table is important for tying i... to e. Every other way I tried to do this was less clear. We can't just strike this unless that is made clear elsewhere.

[mhoemmen]

Pending #90 changes w/ @hcedwar .