From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 11:29:51
These are some conclusions from the review so far:
There is particular (mis) feature in optional which is wrongly
documented (as Peter and William showed me), but
which is also incorrect.
is currently always well defined regardless the initialization state of
If 'opt' is uninitialized, it initializes it to 'x'.
If 'opt' is initialized, it changes its value to 'x'.
This is the exact same behaviour that William suggested be provided by
reset( T const& ) ;
However, the documentation is wrong; but partially because the semantic of
as originally designed is itself wrong.
If *opt appears as an rvalue instead of an lvalue, the result is undefined:
x=*opt; // undefined if opt is uninitialized.
So there is indeed an assymetry.
Furthermore, being able to change the value of an optional
regardless its initialization state is indeed a good idea,
but doing it through operator*() does not map truly
to pointer semantics since you can't do that with a pointer.
That is, my original design that allows *opt=x to be defined
even if 'opt' is uninitialized is actually breaking pointer
Conclusion: I will adopt William's reset, leaving operator*() return
a reference to the optional value *only* if it is initialized
(independently of whether opt is const or not).
Therefore, the proxy is not needed. And so value() isn't needed either.
Since most reviewers wanted it, I will add a safe_bool idiom, which will
conditional expressions like:
if ( opt )
if ( opt == 0 )
if ( opt != 0 )
Having a safe_bool idiom maked 'initialized()' unnecesary, so it will be
However, I'm still unconvinced that uninitialized optionals should compare
and even though, you can always compare optional values (via operator*), so
I see no benefit in defining relational operators directly (thus these
will be poisoned)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk