WAT: opCmp and opEquals woes

[H. S. Teoh via Digitalmars-d]

On Thu, Jul 24, 2014 at 08:36:02PM +0000, Jonathan M Davis via Digitalmars-d wrote:
> 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

Isn't that what the compiler already does?


> 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.
[...]

Keep in mind that the last sentence means that wrong code (i.e.
inconsistent opCmp/opEquals) will silently compile and misbehave at
runtime.


T

-- 
Answer: Because it breaks the logical sequence of discussion.
Question: Why is top posting bad?