Ping. Is there anybody who can take a look at this?

Ping.

I think the intention is that a, a1 and a2 are lvalues of type X, and so using those names does make sense when declaring an lvalue of type X. I'm not sure why Table 27 says "values of type X&" rather than "lvalues of type X"

Thanks. Would you be happy if I simply made the change to "lvalues of type X"?

That would then be inconsistent with the previous row.

I'd like to get the project editor's opinion before changing it. There might be good reasons that row has been unchanged since the 1998 standard, despite adding a row below it. Or there might be no good reason. I don't know.

Sounds good. How do we go about doing that?

I'd like "value of type X&" to be changed to "lvalue of type X", but please do so throughout; there are two others:

source/lib-intro.tex:\tcode{t} & a value of type \tcode{const T&} \ \rowsep
source/lib-intro.tex:\tcode{a, a1, a2} & values of type \tcode{X&} \ \rowsep
source/lib-intro.tex:\tcode{r} & a value of type \tcode{T&}
source/lib-intro.tex:\tcode{s} & a value of type \tcode{const T&}

Note that the a3 row is redundant and should be removed -- a3 is not used by later requirements.

Regarding renaming the variable in the requirement... this is a horrible mess:

• Table 28 uses a and says (in Table 27) that a is a value of type X&
• Table 96 uses u and says "u denotes an identifier".
• Table 99 uses u and says "u denotes a variable".
• Table 100 (sequence container requirements) uses a and says that "a denotes a value of X". (This should also be changed to say "of type X", and there are more such occurrences to fix later in the same paragraph.)
• Table 102 (associative container requirements) uses a and again says that "a denotes a value of X".
• Table 103 (unordered associative container requirements) uses a and says "a is an object of type X", which is even worse than the "denotes a value of" wording. Ugh.

I think we should:

• use u consistently as the name of a variable being declared in a requirements table
• use "u denotes the name of a variable being declared" or similar
• fix the places that say that "a denotes a value of X" to include the word "type"
• fix the places that say "a is an object of type X" to use a more meaningful phrasing

Thanks, Richard. I think I've hit everything you mentioned, and also deleted
several more unused variables in Table 27. Please take another look.

Thanks. @jwakely, I'd appreciate if you could take a look through this and make sure it all looks right to you, especially with an eye to library consistency and any subtle implications that LWG might be making with their choice of placeholder names. I'll also have another look through this before we move ahead with it.

[One other thing: the use of 'value' versus 'lvalue' here has a category error; a 'value' is a result produced by evaluating an expression whereas an 'lvalue' is a kind of expression. I don't think this change reduces consistency, precision, or comprehensibility compared to the prior wording, but I think we can do better here. Equally, T& is listed as a "return type" of an expression in various requirements tables, and that doesn't match the core language either; expressions don't have "return types", and the result type of an expression would not be a reference type. This seems like something LWG should consider more broadly.]

Yes, we should really do better at that kind of thing throughout the library.

I'll take a look at the updated patch asap.

Thanks all. Let me know in detail what you'd like to do about 'value' and 'return type' and I'll be happy to do it.

Ping. Do you mind pulling the commits as-is, assuming they are indeed an improvement, and then pursuing further wording changes separately? I don't mind sending follow-up pull requests.

@jwakely: Ping.

@jwakely: Ping. Can we close this out by using the comments as they are, then pursue larger changes later?

@jwakely: Ping. :-/

I haven't forgotten about this, but last time I tried to merge it locally to review the rebuilt PDF I got several conflicts and didn't have time to resolve them because it's not hugely important. I'll look at it today and see if it can be merged.

Merged as ea16476..1186a38

Wonderful, thank you!