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

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-02-18 11:54:11

David Abrahams wrote:
> "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?
>
Ha, Ok, I got your point wrong.. you mean classes that just won't
compile if operator=() is used.

 With: "if it has copy but no assigment then I better break that code"

I meant the optional<> code that is syntactically (thus conceptually)
doing assignment on a T class that explicitely disallow that.
Since the current implementation uses the copy-ctor under the hood, the
following can happen now:

T a ;
T b ;
b = a ; // forbidden, even though T b(a) is OK

optional<T> oa ;
optional<T> ob ;
oa = ob ; // OK, but it shouldn't.

IMO this is really a bug in optional<T> because if you can't do "a=b" you 
shouldn't be able to do "oa=ob".

So my change will let users uncover such problems (that's what I meant with 
I better break that code)
After all, the old code won't compile anymore, so it won't be a catastrophic 
break as the one that comes from a change in semantics.

Now, that is my personal opinion.

You have the experience of the evolution of the std library, so tell me:
Is introducing a compiler error in old code that used to compile fine (but 
do the wrong thing) a good idea? Is this acceptable?

Fernando Cacciola