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