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