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

"David Abrahams" escribió en el mensaje news:ur7h7yox6.fsf@boost-consulting.com...

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