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
