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: Matt Calabrese (rivorus_at_[hidden])
Date: 2018-03-25 22:27:55

On Sun, Mar 25, 2018, 18:12 Gavin Lambert via Boost <boost_at_[hidden]>
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, 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.