<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 25 July 2014 16:50, Walter Bright via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 7/24/2014 10:52 PM, Manu via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't really see how opCmp == 0 could be unreliable or unintended. It was<br>
deliberately written by the author, so definitely not unintended, and I can't<br>
imagine anybody would ever deliberately ignore the == 0 case when implementing<br>
an opCmp, or produce logic that works for less or greater, but fails for equal.<br>
<= and >= are expressed by opCmp, which imply that testing for equality<br>
definitely works as the user intended.<br>
</blockquote>
<br></div>
Yes, that's why it's hard to see that it would break existing code, unless that existing code had a bug in it that was worked around in some peculiar way.</blockquote><div><br></div><div>Indeed.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In lieu of an opEquals, how can a deliberately implemented opCmp, which we know<br>
works in the == case (otherwise <= or >= wouldn't work either) ever be a worse<br>
choice than an implicitly generated opEquals?<br>
</blockquote>
<br></div>
Determining an ordering can sometimes be more expensive. It is, after all, asking for more information.<br></blockquote><div><br></div><div>Correctness has always been the first criteria to satisfy in D. The user is always able to produce faster code with deliberate effort, and that's true in this case too, but you can't have something with a high probability of being incorrect be the default...?</div>
<div><br></div><div>In lieu of opEquals, and opCmp exists, the probability of being correct is super-biased towards the user supplied opCmp==0, which must already support <=/>= and therefore almost certainly correct, than some compiler generated guess, which has no insight into the object, and can only possibly be correct in the event you're lucky...</div>
<div><br></div><div>I'm a user who's concerned with performance more than most, but there's no way I can buy into that argument in this case. It's just wrong, and the sort of bug that this is likely to produce are highly surprising, very easily overlooked, and likely result in many lost hours to track down. It's the sort of bug that nobody wants to be tracking down.</div>
<div><br></div><div>All that said, I'm not even convinced that there would be a performance advantage anyway. I'd be surprised if the optimiser wouldn't produce correct code for 'a-b==0' vs 'a==b'. These are trivial things that optimisers have been extremely good at for decades.</div>
<div>If I had to guess at which one offered a performance advantage, I'd say that they'd likely be the same (because optimisers work well with that sort of input), or the advantage would go to the user opCmp.</div>
<div>The reason I say that, is that user supplied opCmp may compare *at most* every field (and therefore likely perform the same), but in reality, there's a good chance that the comparison requires comparing only a subset of fields - a user struct is likely to contain some irrelevant fields, cache data perhaps, whatever - and therefore comparing less stuff would more likely yield a performance advantage.</div>
</div></div></div>