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
