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
>>> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>>>> Or to put it another way, if a class is so broken as to support a
>>>> 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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk