Should Maybe move operators really reset()?
Categories
(Core :: MFBT, defect)
Tracking
()
People
(Reporter: mozbugz, Unassigned)
References
Details
The Maybe move constructor and assignment operator reset the moved-from Maybe:
https://searchfox.org/mozilla-central/rev/bc3600def806859c31b2c7ac06e3d69271052a89/mfbt/Maybe.h#413,441
I.e., the moved-from Maybe reverts to a Nothing state (its contained object is immediately destroyed).
Move semantics only suggest that moved-from objects should be placed in a valid but unspecified state.
Another way to think about it, is that the operation of moving from an object is like calling one of its non-const methods: It's up to the object to handle invariants, and there may be preconditions in other methods such that they shouldn't be called on a moved-from state.
For comparison, std::optional (the equivalent of our mozilla::Maybe) explicitly states that the moved-from optional still contains a value, but that value is itself in its moved-from state.
So I personally think we should do the same for Maybe, especially now that we have take() and extract() functions that explicitly reset() their Maybe after its contained object is moved out.
And it could be a small optimization.
Opinions for/against?
Of course, Hyrum's law means that some users of Maybe may rely on this resetting! It should be investigated before we change any behavior.
|
||
Comment 1•5 years ago
|
||
Generally, I am in favor of that. This would also allow Maybe<T> to be TriviallyCopyable if T is.
But changing that now might indeed have unforeseeable effects due to someone relying on the current behaviour.
|
||
Comment 2•3 years ago
|
||
I don't think we should change it at this point. We definitely rely on it resetting in code I've written and reviewed.
|
||
Comment 3•2 years ago
|
||
Reflect comment 1 and 2 in the bug status.
Description
•