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

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2011-09-06 22:50:38

Hi Mostafa,

>> optional<T>
>> f()
>> {
>> optional<T> result;
>> // do stuff
>> return result;
>> }
>>
>
> 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
 >...
 > Or did I miss something in your response?

You totally missed his point. Please allow me to advise you on how to avoid 
that: do not to pick any spot to make a counter-argument. If you do, you'll miss 
the point, and you risk loosing our interest in constructively arguing with you.

In fact, in this particular thread, it is you the one presenting an idea for us 
to discuss, so it is really important that you handle the discussion appropriately.

In Robert's example, it is easy to see--or should be easy to see--that the fact 
that the optional<T> is being returned is secondary, perhaps even irrelevant, to 
the point he is making
His point is about the shortcoming of lacking assignment, not about object 
lifetimes (and BTW, is the same point Nevin and I made earlier).

Perhaps a less distracting example would be:

optional<T> o ;

switch ( cond )
{
   case a : o = foo1(); break ;
   case b : o = foo2(); break ;
   case c : o = foo3(); break ;
   case e : o = foo4(); break ;
   case e : o = foo5(); break ;

   default :  // o remains uninitialized
}

Notice that is quite possible to encounter the above example in real-life, as it 
is common that a variable remains uninitialized in the default case of a switch 
(or, for that matter, in any branch of a complex conditional).

In fact, I even wonder if that example couldn't be considered as the canonical 
use case for optional<>'s assignment operation.

Best

-- 
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com