2018-03-26 0:12 GMT+02:00 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.
However, note that the only problem it would solve is the problem that does not exist when you declare objects rather than references in your scope (in cases you are not interested in object's identity): ``` auto p = func().value(); ``` And everything is correct, shorter, an reflects you intentions more clearly ("I am interested in value, not in address"). Regards, &rzej;