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:
> There is particular (mis) feature in optional which is wrongly
> documented (as Peter and William showed me), but
> which is also incorrect.
> The expression
> 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 operator*()
> as originally designed is itself wrong.
> If *opt appears as an rvalue instead of an lvalue, the result is
> 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 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
William E. Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk