WAT: opCmp and opEquals woes

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 23 17:45:15 PDT 2014


On 7/23/14, 5:28 PM, Jonathan M Davis wrote:
> On Wednesday, 23 July 2014 at 21:36:16 UTC, Andrei Alexandrescu wrote:
>> On 7/23/14, 12:04 PM, H. S. Teoh via Digitalmars-d wrote:
>>> If autogenerating opEquals to be opCmp()==0 is a no-go, then I'd much
>>> rather say it should be a compile error if the user defines opCmp but
>>> not opEquals.
>>
>> No. There is this notion of partial ordering that makes objects not
>> smaller and not greater than others, yet not equal. --
>
> I would strongly argue that if lhs.opCmp(rhs) == 0 is not equivalent to
> lhs == rhs, then it that type is broken and should not be using opCmp to
> do its comparisons. std.algorithm.sort allows you to use any predicate
> you want, allowing for such orderings, but it does not work with generic
> code for a type to define opCmp or opEquals such that they're not
> consistent, because that's not consistent with how comparisons work for
> the built-in types.

std.algorithm.sort does not use equality at all. It just deems objects 
for which pred(a, b) and pred(b, a) as unordered. -- Andrei



More information about the Digitalmars-d mailing list