Re: [boost] Report from Mont Tremblant C++ Committee meeting

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-18 09:44:50

Fernando Cacciola wrote:
>Sam Partington wrote:
> > In the rationale the first example states "If you assign to an
> > uninitialized optional<T&> the effect is to bind (for the first time)
> > to the object. Clearly, there is no other choice".
> >
> > [...]
> >
> > Remove the operator=(const T&)
> >
> > int i = 0;
> > optional< int & >  o(i);
> > int n = 0;
> > *o = i;                        // assigns new value
> > o = optional<int&>(i);  // rebinds, nice and explicitly
>
>The problem which was raised is that it adds an unnecesary verbosity.
>That is, why can't you define:
>
>o = val ;
>
>as a convenient shortcut for:
>
>o = optional<T>(val);
>
>All by itself, is looks quite reasonable.
>
>Now you brought this issue back but into the context of optional 
>references.
>
>Is it totally clear to everyone that this rebinds?
>
>o = optional<int&>(i);
>
>Joel de Guzman said that he wouldn't be against rebinding in this case. 
>He's
>against rebinding in the direct-assignment case, so simply dropping
>direct-assignment is definitely a way out, even at the cost of dropping 
>some
>sugar.
>One could say: optional does not support a convenient direct assignment
>operator becasue it could hide the true semantics of the assignment, which
>are clear if only assignment from another optional is used. (Followed by an
>example)

Why not use partial specialization so that optional< T > has the semantic 
sugar, but optional< T & > does not? Or is this already the case?

>A related note about the use of operator *
>
>You said that, even for optional<T&>, it is clear that this:
>
>  *o = i;
>
>is UB if 'o' is uninitialized. And so there is no problem defining that
>assignment as really just the assignment of the underlying type, which in
>the case of optional<T&> doesn't rebind.
>
>Now I wonder, if instead of operator*, we used value() (or whatever), would
>it be just as clear?
>
>// Nullable interface
>
>*o = rb ; // assing 'b' to 'a'
>o = none ; // releases 'a'
>*o = rc ; // !!! UB !!! Cleary IMO
>
>// Container interface
>
>o.value() = rb ; // assing 'b' to 'a'
>o.reset() ; // releases 'a'
>o.value() = rc ; // !!! Still UB !!! ¿But cleary enough?

I personally prefer the nullable interface as it is more intuitive w.r.t. 
smart pointer usage.
   o.value() = b
reads to me like value() is returning a (temporary) return value, then you 
are assigning rb to that.

Q: If o == none, does *o = foo throw? (I am not familiar with optional<>)

On the optional<bool> side, is it posible to provide a specialization for it 
that doesn't break the optional interface, but still provides the 
functionality that is wanted from an optional<bool> type as discussed 
elsewhere?

- Reece