WAT: opCmp and opEquals woes

[deadalnix via Digitalmars-d]

On Wednesday, 23 July 2014 at 23:52:01 UTC, Andrei Alexandrescu
wrote:
> 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

NaN is a good example.