Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 11:29:51

These are some conclusions from the review so far:

(A)
There is particular (mis) feature in optional which is wrongly
documented (as Peter and William showed me), but
which is also incorrect.

The expression

*opt=x;

is currently always well defined regardless the initialization state of
'opt'.
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
operator*()
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
semantics.

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.

(B)
Since most reviewers wanted it, I will add a safe_bool idiom, which will
allow
conditional expressions like:

if ( opt )
if ( opt == 0 )
if ( opt != 0 )

Having a safe_bool idiom maked 'initialized()' unnecesary, so it will be
removed.

However, I'm still unconvinced that uninitialized optionals should compare
false,
and even though, you can always compare optional values (via operator*), so
I see no benefit in defining relational operators directly (thus these
operators
will be poisoned)

Fernando Cacciola