Notes from 2018-06-Rapperswil LWG review

Meeting wiki notes

My notes:

mdspan LWG review
Daniel Krugler of LWG will help us polish according to LWG expectations

usage of ‘span’ requires reference to C++20 working document
need every section to have stable name
namespace for the TS – std::experimental::fundamentals_v3
before header synopsis a sentence of overview
exposition only in italics k
input iterators has used the term ‘domain’
structure domain and codomain as definitions for this clause in italics; email to the library reflector before the pre-meeting mailing for discussion
LEWG ok with ‘all’ and ‘all_type’
Destructor does not have noexcept
‘noexecept’ typo
typename template layout::mapping
templated member functions “OtherElementType” “OtherLayoutType” …
assignment conversion operator should not be variadic
“DynamicExtent” argument should be “dynamic_extent”
All function arguments in the synopsis are named
Exposition only members are in italics and each is marked with comment ‘exposition only’
perhaps another exposition name than ‘map’
section breaks within synopsis need to have stable names for the subsections, do not have colons
3.2.1
template arguments stated as requirements
“ElementType” shall be …
“Extents” shall be a specialization of extents.
See the algorithm section for templates as policy requirements; policy requirements appear before the synopsis

3.2.2
Cartesian product times sign need to be math font times, put formula in a separate line
Use natural number symbol for extent definition: N_0×N_1 … etc
Omit “(at compile time)” and “(at runtime)”
Ellipses should not be in code font
Marshall – would like an example – would be helpful
Function signature must match the synopsis
Clause for returns should not cover requires clause, add throws nothing
Return for static_extent If rank() <= r then 1
Change all this to “effects equivalent to returns”

3.3 extents
Should be before mdpsan
Destructor after the constructor
… carry Cartesian description to this
Synopsis to state what the class is expected to store – the dynamically sized extents
Would be simpler to describe with exposition only array member of all extents with note that implementation is expected to only store dynamic extents
Template “ExtentsSpecification” name is clearer
Default constructor initializes stored dynamic extents as zero
See optional or variant or span for constructor argument template description / requirements
rank() : returns sizeof…(Extents)
rank_dynamic() : returns number of Extents that are equal to dynamic_extent
static_extent(int i) : if ith < rank() returns the ith element of Extents… ; otherwise 1
throws nothing
constructor needs wording
Shall not participate in overload resolution unless sizeof…(dynamic_extents) == rank_dynamic()
Wording for constructor with arguments talk about input type
Look at tuple equality comparison
3.2.3 Codomain observers
Use math style for i^th
“dynanic” typo
“A span that refers to the codomain”
Ill-formed if requires clauses not satisfied
Use fold expression for IndexType requirement
Wording to prevent “bool” from being used

3.5 Layout Policy Requirements
Split into requirements and specific types
Use “specialized” not “instantiated”
Describe without mentioning basic_mdspan
3.5.2 Concept
Look at allocator and container for table of valid expressions; e.g., Table 77
Preamble to table also a table that identifies symbols
Exposition only layout::mapping<…>::extent ? but very hard to do.
Suggestion – layout::mapping::extents() instead of duplicating ?
Must include the extents-based constructor
3.2.6 has the wording that belongs here
“contiguous” – steal wording from contiguous iterators, remove term ‘span’, no holes in the codomain
Bijective is non-normative note
Wording for strided – true if and only iff …conditions… ; could lead in with “let” …
Wording only refers to extents, layout, mapping
is__strided = / see below */

stride( int i )
returns the distance between codomain when incrementing one coordinate in the domain
0 <= i < rank()

3.2.4 Constructors…
Default constructor is post_condition
Assignment

3.6 Accessor
pointer is a contiguous iterator
need to say what ‘T’ is
An accessor shall meet the requirements …
‘p’ denotes a pointer to a type T

3.5.1 Predefined standard layout policies
This is not in wording !
Preamble “These predefined layout policies are provided…”
Just show code
“row major” and “column major” are notes
Look at container requirements and container for requirements and how they satisfy the layout requirements

TARGET post-meeting

Start with the linked meeting wiki notes and locate the mdspan proposal text reviewed there. Compare the draft with the listed wording, synopsis, terminology, and typo changes; done means the review items are resolved in the proposal.