Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2011-09-08 09:10:31

On Wed, 07 Sep 2011 23:44:42 -0700, Nevin Liber <nevin_at_[hidden]>  
wrote:

> On 7 September 2011 23:15, Mostafa <mostafa_working_away_at_[hidden]>  
> wrote:
>> 1) Were the assignment operator disallowed for optional<T&> and only
>> optional<T&>, there would no loss of programmatic generality when
>> optional<T&> is used as a local variable.
>
> I just don't see a use case for when it is a local variable, ... <snip>

In trying to answer "what are the implications of disallowing the  
assignment operator for optional<T&>" I had to consider the all possible  
use cases of optional<T&>, and they are 1) where optional<T&> is used as a  
local variable, and 2) where optional<T&> is used as a member variable.   
Well, there are namespace variables too, but it's obvious the implications  
are the same as 2).

>
> The case we've mentioned that you haven't covered is returning it from
> a function,

In what respects haven't I covered it?

> which again, is problematic for two reasons:
>
> (1)  Types that are Copyable but not Assignable are surprising

Not necessarily, think of Pimpl.  If I have a Pimpl class heirarchy, then  
operator= becomes problematic for the base class, therefore I disallow it  
in all cases.

What about using such a Pimpl in stl-like containers?  Answer, use the  
opaque handle of the Pimpl, and reconstruct the Pimpl from the opaque  
handle where necessary.

> (2)  It is rare to return a reference anyway, as something outside of
> the callee has to manage the lifetime of the underlying object

Not that rare.  Let's say I'm using raw-pointer/reference idiom to convey  
the semantics of optionalness, then returning a reference is certainly an  
option.  I believe it's the callee that has to manage the said lifetime.

Mostafa