Re: [boost] [optional] get() misses optional r-value overload in contrast to operator* and value()

Subject: Re: [boost] [optional] get() misses optional r-value overload in contrast to operator* and value()
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-03-26 06:31:07

2018-03-26 0:12 GMT+02:00 Gavin Lambert via Boost <boost_at_[hidden]>:

> 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;