On Sun, Mar 25, 2018, 18:12 Gavin Lambert via Boost
On 25/03/2018 13:50, Peter Dimov wrote:
No, both are correct; optional::value()&& returns an rvalue reference to the value inside the optional, to which the auto&& or auto const& binds. When the optional temporary is destroyed, this reference becomes dangling.
Doesn't this problem go away if value()&& is removed entirely, or at least changed to return by value instead?
Granted I haven't done much delving into the darker corners of C++11, but I've usually found that outside of implementing std::move itself, anything that returns a T&& is probably a bug waiting to happen.
T&& value()&& { return std::move(t_); }
In this case, this should be just as efficient:
T value()&& { return std::move(t_); }
Especially with improved elision guarantees in more recent standards and compilers.
I do not recommend doing that. It has different semantics from the other overloads and can be a pessimization for certain types. I think the correct answer here, as harsh as it sounds, is "use the API correctly". I do not see a defect here.