[Boost-users] Re: [optional] self-assignment and assignment of references

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-19 06:41:09

"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.

Some (sensible, correct) choices simply can't be justified on the
basis of logic.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com