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.
