WAT: opCmp and opEquals woes

David Gileadi via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 23 11:26:16 PDT 2014


On 7/23/14, 11:09 AM, Dicebot wrote:
> On Wednesday, 23 July 2014 at 17:15:12 UTC, Ary Borenszweig wrote:
>> Imagine you have a list of integers and strings denoting integers: [1,
>> "2", 100, "38"]. Now you want to sort them according to their numeric
>> value. Of course, 1 and "1" would have the same order. However, 1 and
>> "1" are different, so "==" would give false, while 1.opCmp("1") would
>> give 0.
>>
>> Equality and comparison are different. opCmp is used for sorting
>> objects, which has nothing to do with equality. Inferring equality
>> from opCmp is wrong in my opinion.
>
> Well this is why you can actually override those :) I think automatic
> opCmd -> opEqual generation covers vast majority of use cases and as
> such will have a vary good effort / decreased annoyance ratio.

I agree. In fact I think if you've implemented opCmp to sort 1 and "1" 
as equal that in most cases you'd expect "1" and 1 to compare as 
logically equal. Automatic opCmp -> opEquals seems like a very sane 
default to me.


More information about the Digitalmars-d mailing list