-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
C.65 Self-move - require only valid but unspecified #1938
Conversation
CppCoreGuidelines.md
Outdated
// ... | ||
~X() { delete owning_ptr; } | ||
private: | ||
T* owning_ptr; // bad (See R.20) but used in the example because |
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 couldn't think of a simple example that required a manual move-assignment that didn't go against something in the guidelines
}; | ||
|
||
Foo& Foo::operator=(Foo&& a) noexcept // OK, but there is a cost | ||
X& X::operator=(X&& a) noexcept |
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.
Used 'X' instead of 'Foo' to match C.64
This seems more radical than #1606:
As I recall, response to #1606 stalled because there was a draft paper on that topic. |
Can we use 'valid-but-uspecified' until it is offically settled? I don't think it is practical to have the rule stronger than what the stl types do. Any type with an stl memeber that uses the rule of zero or |
I like the Idea to stick with the stl behavior for now, but would love to see more data about the need for stronger rules. Has anyone had anekdotal or regular encounters with a self-move outside of self swap (where you don't care about the value)? What were the consequences for this? |
Editors call: This would invert the guidance and we agree with the current guidance -- self-move should be a no-op. |
Cleaned up C.65: Make move assignment safe for self-assignment
based on the discussions in #1892 #1649 #1606.