Boost Users :
From: David Abrahams (dave_at_[hidden])
Date: 2005-04-19 06:41:09
"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> Hi people,
> Recently, here:
> 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
> Rationale for Boost.Optional assignment semantics:
> 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
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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net