Comparators should return num instead of int

[DartBot]

This issue was originally filed by @seaneagan

---

The only thing that matters about the return type of a comparator is whether it is less than, equal to, or greater than zero. Thus, it should be typed num to avoid unnecessary conversions and checked mode errors.

// see issue #1492
Comparable#compareTo
num compareTo(T other);

typedef num Comparator<T extends Comparable>(T other)

List#sort
sort([Comparator<E>]);

[sethladd]

Set owner to [email protected].
Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

[rakudrama]

I'm curious when you see unnecessary conversions and checked mode errors.
I have not had this problem myself.
In general you should not compare doubles by doing subtraction as it behaves badly for infinities.

[DartBot]

This comment was originally written by @seaneagan

---

On the VM at least, in checked mode, returning a num or double from a comparator which has return type int should throw a type error.

Comparing nums or doubles using subtraction would be the main use case for returning num instead of int, though I guess the suggested way to do this would instead be:

double1.compareTo(double2)
num1.compareTo(num2)

in which case, forget about this bug.

It might be good to add something to the Comparable documentation about this.

[DartBot]

This comment was originally written by [email protected]

---

I've been thinking about moving away from 3-valued comparators, or at least offering other options (individual <, <=, ==, >=, >). Three-valued comparators have caused many subtle bugs over the years. Dart is impervious to some of them, due it to its arbitrary precision approach to int arithmetic. But three-valued comparisons are more costly than two, and violate the principle that you shouldn't have to pay for more than you use. I'm thinking about this issue in conjunction with other collections issues.

[alan-knight]

Re-assigning, as jjb isn't here any more.

---

Set owner to @lrhn.

[lrhn]

We are not going to change compareTo to return num.

I share Josh's discomfort with the three-value comparators, but the alternatives aren't better.
The only real improvement we could do was to return an enum (GREATER,SMALLER,EQUAL) instead of an int, but I don't think it's enough of an improvement to warrant the change.

The problem here is that there are different use-cases for comparing.
When you just have two objects, you may just want to check <, <=, >= or >, and you can often do that cheaper than computing the full compareTo result.
On the other hand, when you are sorting or otherwise ordering (e.g., a tree-based data structure), you very much want the full three-option result in a single operation, and having to do < and then > (or == or reversed < again) will be more expensive.

So we want both.
Preferably I would have both the comparison operators and the compareTo operation on comparable types, so that you can pick the one you need, and we can optimize each one individually. And they should be compatible if possible (coughNaNcough).
Not everbody agrees on that, though, which is why we don't have "<" declared on the comparable interface. :)

---

Added NotPlanned label.