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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
