Consistent cv-qualification notation #3660
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…"reference to cv2 T"
|
Please create separate github issues for the other concerns. |
|
@jensmaurer I committed one of the commits to the wrong branch; should be fixed now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are a lot of inconsistencies in how we specify cv-qualifiers in the text, so I went through and fixed most of the more offending examples. Most of the changes involved replacing "possibly cv-qualified" where cv could be used, however there were a few other things I went ahead and fixed:
The "house style" is to say "possibly cv-qualified", but there are two occurrences of "optionally cv-qualified". One was changed to use cv, the other was changed to the correct phrasing.
[dcl.init] p 17 sub 6.2.2 Introduces the named type
A, but doesn't reference it again.[over.match.copy] had a type with described as "reference to possibly cv-qualified
T". Quite obvious what's wrong there.A couple other more unrelated things I noticed going through:
[basic.type.qualifier] p2 is made redundant by [basic.type.qualifier] p6, and [basic.type.qualifier] p3 can probably be turned into a note.
In [dcl.init.list] p2 we say that constructors take
std::initializer_list<E>and references to possibly cv-qualifiedstd::initializer_list<E>are initializer list constructors. I think cv is missing from the first one, but that is definitely not editorial.In [conv.ptr] p3 we say "The null pointer value is converted to the null pointer value of the destination type.". The definite article does not seem to fit there, as a specific null pointer value was not established (presumably its referring to a derived to base pointer conversion where the value of the derived pointer is a null pointer value)
[temp.deduct.partial] p5 and [temp.deduct.partial] p7 are a little excessive for what they do. All other instances of this is done in a much less verbose fashion e.x. [temp.deduct.call]
In [over.built], every occurance of "every cv-qualified or cv-unqualified [...]
T" can simply be replaced with "every [...] cvT".This is a little outside the scope of what I was looking for here, but the 3 paragraphs in [class.init] are just watered down versions of the wording they link to. These paragraphs could just be removed, or turned into notes, as they don't serve any normative purpose.