21 [language.support] comments from Axel

[camio]

21.12.2 [reflect.synopsis]

"template concept Constant; // refines Scope and ScopeMember"
should read
"template concept Constant; // refines Typed and ScopeMember"
(as per P0670R4)

I don't think the standard hyphenates comments, as is done in the
"refines" comments for the concepts. Instead, comments are continued by
adding a new comment on an empty line, indenting that new comment
aligned to the previous one. See e.g. the example at the end of 10.1.7.2.

// 21.12.4.1 Object operations
has most operations <class T>, not <Object T>. That's weird. Is that
editorial? I believe LWG and CWG would be surprised by the current
wording. As is I believe we can get this editorially fixed.

21.12.3 - should these paragraphs be numbered? Looking at e.g.
[alg.all_of] we should probably number them.

21.12.3.7, "Variable<T> is true if and only if T reflects a variable or
non-static data member."

This reads as if static data members are not Variables. Because static
data members are variables they still Variables - but this is really
awkward, basically playing games with the reader. I suggest "Variable<T>
is true if and only if T reflects a variable or data member."

21.12.3.11, English natives please confirm: "Any such T does not satisfy
ScopeMember." -> "No such T satisfies ScopeMember.

Roger: In my opinion these are equivalent, but the similarity of the original to
other wording in 21.13.3.10 [reflect.concepts.namespace] and 21.13.3.15
[reflect.concepts.scope] might be worth retaining?

David: Leaving as is.

21.12.4 Meta-object Operations [reflect.ops]
"Operations" should be lowercase.

Paragraph numbers?

21 (in general)

Comment should not have a line-break.

21.12.4.1, get_source_line should be <Object T>

21.12.4.1, get_source_column, "of the entity or typedef described by T"
has a weird 3 hanging out over the word "described". Is that a Chrome bug?

21.12.4.2, get_element and unpack_sequence have a "Remarks:" paragraph
that none of the other operations have. I suggest to strike "Remarks:".

21.12.4.2, struct unpack_sequence; seems to fit into the previous line?

21.12.4.3 [reflect.ops.named]

"All specializations of get_name and get_display_name"
-> "All specializations of get_name<T> and get_display_name<T>"

RO: I'm not sure about this change. The standard doesn't do this for tuple_size,
for instance:
19.5.3.6 [tuple.helper]
template<class T> struct tuple_size;
Remarks: All specializations of tuple_size shall satisfy...

David: I'm changing to <T> for consistency with the other wording in this section.

"for T reflecting an conversion function" -> "for T reflecting a
conversion function" (an -> a)

"the same characters as get_name_ve<R>" -> "the same characters as
get_name_v<R>" (stray 'e' in front of '<')

Should the "Remarks:" introducer be removed?

21.12.4.5 [reflect.ops.type]

In the 2nd example for get_type:

"C1 will reflect int[17][] while C2 will reflect int[17][42]"
-> "C1 reflects int[17][] while C2 reflects int[17][42]"

Too little vspace before
template <Type T> struct get_reflected_type;
Too much behind it, likely related to what Roger commented: "Just before p5 "template <Type T> struct get_reflected_type;" needs to

change to code font"

is_enum, is_union is calling out is_enum and is_union, while is_class,
is_struct says "of these templates".

template <Record T> struct get_destructor;

claims to return an ObjectSequence; I believe that's a wording bug that
came out of the last review round, where "get_destructors" was renamed
to "get_destructor". We should apply the following change editorially:

Roger: Happy with the change, not 100% sure we can make that editorially ... what
do others think?

Move "get_destructors" after the paragraph specifying
template <Record T> struct get_constructors;
template <Record T> struct get_destructor;
template <Record T> struct get_operators;

template <Record T> struct get_destructor;
All specializations of get_destructor<T> shall meet the
TransformationTrait requirements (23.15.1). The nested type named type
is an alias to a Destructor type that reflects the destructor of the
class reflected by T.
The program is ill-formed if T reflects a closure type.

David: I went ahead with the change. I think this is borderline editorial.

21.12.4.9 get_constant

Stylistic mismatch with the other get_... Change:

"It has a static data member named value whose type and value are those
of the constant
expression of the constant reflected by T."
->
"The type and value of the static data member named value are those of
the constant expression of the constant reflected by T."

Or we need to at least fix the "It", referring to "All specializations
of get_constant<T>".

get_pointer: "X is the pointer-to-member type of the member variable
reflected by T and x a pointer to the member." I prefer "to that member".
21.12.4.20, "All specializations of this template" -> "All
specializations of is_explicit<T>"

Same for 21.12.4.22, 21.12.4.23, 21.12.4.24. This should be uniform,
either "this template" or repeat the template throughout.