-
Notifications
You must be signed in to change notification settings - Fork 772
[class.copy.assign] Fix phrasing in note #4418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
(I like it and will apply it if there are no objections.) |
source/classes.tex
Outdated
an assignment operator of the derived class, | ||
even if the base class assignment operator, | ||
when considered as a member of the derived class, | ||
is a copy assignment operator or a move assignment operator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the "is" because the assignment operator never is one of those things. I already provided my own variation that avoids that phrasing, but maybe it's inferior in some other way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I see what you mean, and I agree. Something like "would" is really what we'd need here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merging the two suggestions, how about:
A using-declaration in a derived class
C
that brings in an assignment operator from a base class never suppresses the implicit declaration of an assignment operator ofC
, even if the base class assignment operator would be a copy or move assignment operator if declared as a member ofC
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine, except that "brings in" is a reversion from "names" in P1787R6, which says that using-declarations do not copy-paste declarations around. (Admittedly, this is (now) a note, but I don't want to encourage the old way of thinking.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. How about this then:
A using-declaration in a derived class
C
that names an assignment operator from a base class never suppresses the implicit declaration of an assignment operator ofC
, even if the base class assignment operator would be a copy or move assignment operator if declared as a member ofC
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean that "from a base class" is redundant? If so, then yes, that's true, but in a note this seems helpful explanation, since it's exactly the puzzle solving that would be needed in the absence of this explanation that the note tries to spell out. (We could also say "an assignment operator (from a base class)", or "an assignment operator, which must be from a base class". But we shan't.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@opensdh: I know you were already OK with this, but could you take a final look? I appreciate your eye for avoiding ambiguity and redundancy!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No new opinion here. If someone has a brilliant rephrasing idea, that can be a separate change later that doesn't have the burden of "could".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, merging!
To recap/abstract the interesting point of the recent discussion: A phrase "a thing X that is a thing Y" can have two purposes: it can either constrain the set of possible Xs to those that are also Ys, or it can merely point out that an X is also always a Y, but both the property X and Y are importent to the context. In normative wording we might want to avoid the second construction, but in normal English I find it perfectly reasonable, and so it is also reasonable in this note.
"I touched the cold snow" doesn't mean I carefully selected the particular kind of snow that I picked up, but simply that my hands were getting cold.
to avoid 'could'.
@tkoeppe, this looks ready. |
@jensmaurer: Yeah, I had still been ponderin Davis's remark about the redundancy of saying "from a base class". I think it's helpful to say that, though, and I can't think of a way to make it more parenthetical. Absent any better ideas we can apply this. |
@tkoeppe, any final thoughts here? |
to avoid 'could'.
Fixes #4388