https://issues.dlang.org/show_bug.cgi?id=16657
--- Comment #5 from Eyal <[email protected]> --- We had something like this: if(x != y) { x = y; // expensive assignment } // assume all x fields equal y fields here, we assign them all -- ouch! The semantics now are very surprising: x = y // assigns the whole of "x", not just the "alias this" part x == y // compares just the "alias this" part, wat? Well-behaved assignments and equalities should apply to the same part of the object. That the auto-generated assignment/equals code is NOT well-behaved is surely to be considered a bug. Implementation-wise: It is quite simple to always auto-generate opEquals that compares all fields with == recursively calling opEquals. The auto-generated opEquals overrides the "alias this" opEquals for the (Subtype,Subtype) case. I don't see where the implementation difficulty comes in here. In Walter's example, auto-gen'd C.opEquals would use == on both fields, implicitly invoking opEquals of A. No special cases or exceptions. --
