Skip to content
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

[class.copy.assign] Fix phrasing in note #4418

Merged
merged 1 commit into from Oct 26, 2021
Merged

Conversation

jensmaurer
Copy link
Member

to avoid 'could'.

Fixes #4388

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 14, 2020

@opensdh: could you take a look? This is wording proposed by @zygoloid.

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 14, 2020

(I like it and will apply it if there are no objections.)

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.
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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 of C, even if the base class assignment operator would be a copy or move assignment operator if declared as a member of C.

Copy link
Contributor

@opensdh opensdh Dec 15, 2020

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.)

Copy link
Contributor

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 of C, even if the base class assignment operator would be a copy or move assignment operator if declared as a member of C.

Copy link
Contributor

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.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Copy link
Contributor

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!

Copy link
Contributor

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".

Copy link
Contributor

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.

@jensmaurer
Copy link
Member Author

@tkoeppe, this looks ready.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jul 5, 2021

@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.

@jensmaurer
Copy link
Member Author

@tkoeppe, any final thoughts here?

@tkoeppe tkoeppe merged commit 741c207 into cplusplus:main Oct 26, 2021
@jensmaurer jensmaurer deleted the c19 branch October 26, 2021 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[class.copy.assign]p8 needs rewording
3 participants