[Boost-users] Re: [optional] self-assignment and assignment ofreferences

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-04-19 16:41:04

"David Abrahams" <dave_at_[hidden]> escribió en el mensaje 
news:ur7h7yox6.fsf_at_boost-consulting.com...
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>
>> Hi people,
>>
>> Recently, here:
>>
>> http://lists.boost.org/MailArchives/boost/msg78947.php
>>
>> Joe Gottman pointed out that optional<T> fails on aliasing situations
>> like self-assignment, and proposed to forward assignment to
>> T's assignment operator (when the lhs is initialized).
>>
>> In the current implementation, Optional's assignment uses a
>
> <snip>
>
>> Rationale for Boost.Optional assignment semantics:
>
> <snip>
>
>> Following the logical expectation of requiring optional<T> to follow T
>> as much as possible, one would expect:
>>
>> ora = orb ;
>>
>> to change the value of the referee (a) to that of 'b'
>>
>> But there is a catch:
>>
>> As the song goes, optional<T> can follow T down but not that far. :-)
>>
>> The reason is that assignment must operate on optional<T> itself, so
>> it must be well defined in the case it is uninitialized, and there
>> it just can't follow T's behaviour.
>>
>> If 'ora' is uninitialized, 'ora = orb' can ONLY rebind the
>> wrapped reference to 'b' if you expect any kind of equivalence
>> to be the postcondition of the assignment.
>> It clearly can't just ignore the assignment cause there is
>> no referee to change its value.
>
> I don't have a strong opinion about which semantics optional<T> should
> adopt, but IMO this logic is a flawed way to justify your choice.  An
> optional<T> (where, in this case, T = U&) can be viewed as a variant
> type:
>
>       T | void
>
> An uninitialized optional<T> takes the void branch of the "or."  When
> orb holds a U& rather than a void,
>
>   ora = orb
>
> is essentially replacing the void with a new U& and initializing it
> with whatever is in orb.
>
I suppose you're saying that given what you wrote, and the fact (left 
implicit)
that when 'ora' takes the 'T' branch a variant type could just
assign the referred value but not rebind, then the choice of what to do in 
the
already initialized case just don't follow directly from the only possible
option in the uninitialized case.

If that's the case, you're right, though I didn't intend to make my choice 
appear as a logical consecuence of the constrain (when uninitialized it must 
bind to the reference). I rather intended to show the constrain as a mere 
motivation for the choice. Clearly others choice are still valid.

Fernando Cacciola
SciSoft