WAT: opCmp and opEquals woes

[H. S. Teoh via Digitalmars-d]

On Fri, Jul 25, 2014 at 09:22:26PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/25/2014 8:41 PM, Manu via Digitalmars-d wrote:
[...]
> >It may be correct, if you're lucky, and that's the best offer you'll
> >get.  opCmp==0 however is practically certain to be correct, since <=
> >and >= are required to work... and the api embodies the concept of
> >equality, it would be very hard to write an implementation where
> >equal was broken, but <,<=,>=,> all worked.
> 
> At this point, it's obvious we are going around in a circle. You ask
> the same questions over and over, and I answer them over and over. If
> you don't want to accept that equality and comparison are
> fundamentally different operations, I can only repeat saying the same
> things.

Well, we can argue about this until the cows come home, but at least for
the present regression being addressed, I think Jonathan's fix is the
best option (or the least of all evils): revert the compiler change that
causes a compile error when the user defines opCmp but not opEquals.

In the meantime, I think much of the confusion comes from the current
documentation not be adequately clear about the reasoning behind having
opCmp and opEquals, so it's too easy to get the wrong impression that
defining opCmp is enough to make things work, or to have a fuzzy
inaccurate understanding for how opCmp interacts with opEquals, and
when/why to use each. I think a documentation PR is in order.


T

-- 
I don't trust computers, I've spent too long programming to think that
they can get anything right. -- James Miller