WAT: opCmp and opEquals woes

[Andrei Alexandrescu via Digitalmars-d]

On 7/23/14, 3:39 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Jul 23, 2014 at 02:35:03PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 7/23/14, 11:52 AM, H. S. Teoh via Digitalmars-d wrote:
> [...]
>>> I fully agree that we should not autogenerate opCmp if the user
>>> defines opEquals, since not all types comparable with equality are
>>> orderable.  However, surely all orderable types are
>>> equality-comparable!
>>
>> http://en.wikipedia.org/wiki/Lattice_(order)
> [...]
>
> And why should this be the default behaviour? The <, <=, >=, > operators
> imply linear ordering, not general partial order. If you really want to
> implement a non-linear partial ordering, you can always define both
> opCmp and opEquals. This should be the *non*-default case, since in the
> vast majority of cases, defining opCmp means you want a linear ordering.
> Linear ordering should be default, and partial ordering possible if the
> programmer explicitly asks for it (by implementing opEquals manually).

I'm unconvinced. Most algorithms that need inequality don't need 
equality comparison; instead, they consider objects for which both !(a < 
b) && !(b < a) in the same "equivalence class" that doesn't assume they 
are actually equal.

Bottom line, inferring opEquals from opCmp seems fishy.


Andrei