"Fernando Cacciola"
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