WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Thursday, 24 July 2014 at 19:35:12 UTC, Andrei Alexandrescu 
wrote:
> I like Daniel's idea to auto-define opEquals as a 
> field-for-field comparison. -- Andrei

That's basically what the compiler-generated opEquals does 
(though I think that it'll just to a memcmp if it knows that it 
can get away with that). So, if that's what you want, you're 
arguing for just have the compiler still define opEquals for you 
even if opCmp is defined. And I'm fine with that, but if the 
concern is code breakage for AAs, and opCmp is not defined in a 
way that's consistent with opEquals, then that would break them. 
Now, I think that such types are buggy, so I'm not sure that 
that's all that big a deal, but if I understand correctly, 
basically anything that we do with 2.066 which doesn't involve 
continuing to use lhs.opCmp(rhs) == 0 for the AAs will break 
them, and we need to change it to use opEquals, so I'm not sure 
that we _can_ avoid code breakage unless the type defines 
opEquals, and it defines it in a manner which is consistent with 
opCmp (which it _should_ do but might not). And if that's the 
case, then it just comes down to what type of code breakage we 
want to incur. And IMHO, having the default opEquals continue to 
be generated when opCmp is defined is a very workable solution, 
since no types should have defined opCmp in a way that was 
inconsistent with opEquals.

- Jonathan M Davis