WAT: opCmp and opEquals woes

[Manu via Digitalmars-d]

On 25 July 2014 16:50, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 7/24/2014 10:52 PM, Manu via Digitalmars-d wrote:
>
>> I don't really see how opCmp == 0 could be unreliable or unintended. It
>> was
>> deliberately written by the author, so definitely not unintended, and I
>> can't
>> imagine anybody would ever deliberately ignore the == 0 case when
>> implementing
>> an opCmp, or produce logic that works for less or greater, but fails for
>> equal.
>> <= and >= are expressed by opCmp, which imply that testing for equality
>> definitely works as the user intended.
>>
>
> 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.


Indeed.

 In lieu of an opEquals, how can a deliberately implemented opCmp, which we
>> know
>> works in the == case (otherwise <= or >= wouldn't work either) ever be a
>> worse
>> choice than an implicitly generated opEquals?
>>
>
> Determining an ordering can sometimes be more expensive. It is, after all,
> asking for more information.
>

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...?

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

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.

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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140725/9fa10b65/attachment-0001.html>