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 rules for overloading as rvalue #712
Comments
I'd prefer to not make any changes here until P0135 lands, because it's going to change this wording. |
P0135 has landed. |
in a throw-expression or a return statement. Fixes cplusplus#712.
in a throw-expression or a return statement. Fixes cplusplus#712.
in a throw-expression or a return statement. Fixes cplusplus#712.
in a throw-expression or a return statement. Fixes cplusplus#712.
in a throw-expression or a return statement. Fixes cplusplus#712.
in a throw-expression or a return statement. Fixes #712.
Does anyone know which proposal this change corresponds to? |
Could you try git-blame until you find the motion application commit? |
Yes yes, right, now continue git-blaming from before that commit, look where the previous content came from, etc. |
I believe these rules are entirely misplaced in a "copy elision" section. After all, elision is optional, but moving is mandatory. I'm trying to fix this in #3998. |
@tkoeppe |
@nullptr-cpp: I don't know and would just do the same thing I advised. If you get all the way to commit 1, then this wording has been there since before C++11 and we'd need to look much harder. |
@nullptr-cpp: Yes, the original wording "When the criteria for elision" was already present in the first commit on GitHub: Line 3052 in d8fb8cf
|
The rule for potentially selecting the the constructor as if the object were an rvalue currently reads as:
This is a very long sentence with lots of internal boolean operators, and every three months I come across this sentence and mis-parse it. It would be great to come with with a rewording of this such that it's obvious what the two cases are. Something to the effect of:
Or really any other kind of editorial wizardry to clearly separate the two conditions that lead to the rvalue overload being considered.
The text was updated successfully, but these errors were encountered: