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-06 19:23:55

On Tue, 06 Sep 2011 07:31:23 -0700, Stewart, Robert  
<Robert.Stewart_at_[hidden]> wrote:

> Mostafa wrote:
>> On Fri, 02 Sep 2011 11:10:01 -0700, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> > Mostafa wrote:
>> >>
>> >> Ahh, I disagree with that.  IMO, if maybereff was not bound
>> >> at construction time, then it should always remain
>> >> "uninitialized".
>> >
>> > If the only way to make a non-empty optional<T&> is to
>> > construct it from a reference, then it couldn't be used, for
>> > example, as a function return type.
>>
>> A non-empty maybereff can be bound at construction time via
>> construction from a T& or from construction from a non-empty
>> optional<T&>.> The latter would allow it to be used as a
>> function return type.
>
> Right.  When I wrote the above, however, I was thinking of the more  
> generalized usage that is possible with optional, though I didn't say so:
>
> optional<T>
> f()
> {
>    optional<T> result;
>    // do stuff
>    return result;
> }
>
> Since copy assignment isn't permitted in your idea, that wouldn't work.   
> That means even less generality, so a new type would definitely be in  
> order if shown to be sufficiently useful.

I'm presuming that in your "do stuff" section there is going to be  
something along the lines of "result = ...".  If so, then:

In this thread-path I was exploring disallowing assignment for  
optional<T&> and only optional<T&>.  Hence the above example should work  
for all types T that are not references, but fail for types T that are  
references.  However, in the latter case, there is no loss of generality  
since the above would still be a no-no where T a reference type and  
assignment allowed for optional<T&>.  Or did I miss something in your  
response?

There is some loss of generality w.r.t. to the existing behaviour of  
optional when optional<T&> is a member variable and one would want to  
return it from a method, since optional<T&>'s initialization is then  
restricted to its enclosing objects construction.  However, that is how  
one would expect the underlying T& type to behave from the outset.

Mostafa