[boost] Re: [bug]: optional<T> fails on self-assignment

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-18 10:29:47

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> escribió en el mensaje 
> news:umzu3t5yn.fsf_at_boost-consulting.com...
>> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>>
>>> Or to put it another way, if a class is so broken as to support a 
>>> reasonable
>>> copy-constructor (which is a current requirement), but not assignment, 
>>> then
>>> I'm probably doing him/her a favor by breaking it :-)
>>
>> ?? Any immutable or const type should fit that description.
>>
> A const type is not a class. A class by itself would support proper 
> assignment even if you can't use it on a const lvalue.
>
> IOW, if you have a proper copy ctor you must have a proper assignment 
> operator. 

I don't follow.  I can build a type that can't be mutated through
assignment, yet can be copied.  It seems like a thoroughly coherent
design to me.  You're saying it's invalid?

> Or are you referring to classes which do implement operator=() but 
> purposedly to do something semantically different than to yield two 
> equivalent objects in the exact same way a copy-ctor will produce them?

No; that _is_ abominable.

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