David Abrahams wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:umzu3t5yn.fsf@boost-consulting.com...
"Fernando Cacciola" <fernando_cacciola@hotmail.com> 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