Boost logo

Boost :

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.


Fernando Cacciola
SciSoft Consulting, Founder

Boost list run by bdawes at, gregod at, cpdaniel at, john at