Re: [boost] Formal review: Optional library

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-11 12:00:08

Fernando Cacciola said:
> 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)

I like what this is sounding like, but think I have a few more things to
say.  Before I do so, however, I'd like to see precisely what the no
interface looks like.  You don't have to repeat the semantic descriptions,
just show us the public interface.  There are a few things you've said
here that aren't totally clear with out this.  For instance, does
"uninitialize()" become "reset()"?  What about the issue of
"deep-constness"?

Thanks,

William E. Kempf