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.