What about "non-const value of type X" and similar phrasings? They also look wrong.

For the "non-const value of type X" cases, I am not sure it is immediately clear that X cannot be a const-qualified type. Thus, LWG should probably inform as to whether remove_const_t was meant, or if "type X (X possibly being const)" was meant, or if "type X (X being non-const)" was meant.

"non-const value of type X" means a value of type X where X must be non-const.

For the container requirements tables we could define X as a non-const container type in the first place, then simply "type X" would mean the non-const case, and then when we want to talk about operations that are valid on const or non-const objects we can say "of type X or const X".

e.g. "X denotes a container class of a non-const type, containing objects of type T" (I would prefer not to say "denotes a non-const container class" in case someone thinks that implies there are such things as "const containers" and "non-const containers".

For table 86 "t denotes an lvalue or a const rvalue of type X" would become "t denotes an lvalue of type X or an rvalue of type const X" and so on.

This will likely cause editing conflicts with #117.

Do we agree that this change is correct and desirable (but not being done at this time)?

Because I made the same edits in the Networking TS and @mclow has questioned the validity of the change, as they weren't made by any approved motion. I consider it an editorial correction, assuming this issue is correct.

I agree that "const" applies to a type, not to a value (although a value has a type), and thus rephrasing this in terms of types is good. The remaining question is whether the X in "X or const X" phrasings might be const to start with. I don't remember whether we've got clearer phrasing the core language sections for this, and also for the distinction "X shall not be a cv-qualified type" vs. "remove top-level cv-qualifiers from X". Right now, C++17 is top priority, though.

Personally, I think the existing phrasing in the library requirements sections

a and b denote values of type (possibly const) P

is more clear than

a value of type X or const X.

But if you and Jens think that's not correct and the latter is preferable, I can live with that.

@mclow: The issue here is "a possibly const value of X". And that seems plain wrong (26.2.6p8). I do recognize "values of type (possibly const) P" is used in the library section, and that's an improvement, while still concise. I don't really fancy the repetition of X in "of type X or const X".

I think "of type (possibly const) P" is less clear: it can be read as saying "of type P (where P is possibly const)". Whereas "of type P or const P" does not admit such a misinterpretation. Let's try that and see how it looks.

Let's keep this issue open, as there is unresolved discussion in #1563 and a related LWG issue.

And @jensmaurer asked:

I wish we had some shorthand along the lines of "value of type cv X" or so.

We don't want to include volatile, but I think we already have other places in the library where we say cv T and mean possibly const T.

We also have a mix of "T or const T" and "(possibly const) T" which isn't the end of the world, but could be harmonised.