Gavin Lambert wrote:
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,
No...
or at least changed to return by value instead?
Yes.
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_); }
I consider it an open question whether T or T&& is "more correct" here. Return by value is less efficient (one extra move) if you pass the result to a function taking T&&, and it has the downside of actually moving when you call std::move(opt).value() without doing anything with the result. But the lifetime problems are a bit nasty. Ideally if something like http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf goes through the compiler would know to extend the lifetime of the optional temporary. Or perhaps we could declare defeat, go back to Cfront days and extend all temporaries instead. :-)