N4494: Multidimensional bounds, offset and array_view, rev. 6 -- Łukasz Mendakiewicz, Herb Sutter
New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.
Document number: N4494
Date: 2015-05-01
Multidimensional bounds, offset and array_view, revision 6
by Łukasz Mendakiewicz and Herb Sutter
Excerpt:
Revision 6 (N4494) incorporates the changes requested by LWG in Cologne meeting, marked as deletions and insertions.
The following suggestions were implemented fully:
The following suggestion was implemented partially:
- Rephrased coord.general avoid references to mathematical entites.
- Renamed index to offset.
- Changed int Rank template parameter to size_t Rank throughout the document.
- Made offset, bounds and bounds_iterator binary operators (apart from @= forms) free functions.
- Replaced term "component" with "element" when referring to the individual constituents of offset or bounds.
- In coord.bounds.require replaced prose with an equivalent mathematical expression.
- In coord.bounds.iterator and coord.bounds.iterator.require removed the requirement on bounds_iterator to represent a random access iterator, replacing with "as-if" phrasing.
- In the description of bounds_iterator& operator++() replaced the code snippet with equivalent prose.
- In views.general changed the font back to non-monospace.
- Removed views.require, duplicating it as arrayview.require and stridedarrayview.require.
- Removed redundant assignment operators on array_view and strided_array_view.
- Employed "exposition only" data members is the descriptions of array_view and strided_array_view semantics.
- Rephrased the first paragraph in arrayview.cons to avoid ambiguity in binding of the token "type".
- In constexpr array_view(Viewable&& vw) rephrased the third bullet point.
- Instead of the array_view(ArrayType& arr) constructor being completely removed, it has been constrained to 1-D case as the Committee indicated that such case does not exhibit the undefined behavior. We believe that the request to remove it completely was a misstatment.
The following suggestion was not implemented:
- The semantics of the proposed types were not extended to allow rank-0 cases. We feel that we lack sufficient practical experience in using such cases and we are afraid of some contention points when it comes to defining their detailed semantics. We observe that such an extension can be introduced in future without conflicting with the proposal in the current form.