Comparable Interface Should Include Comparison Operators

[DartBot]

This issue was originally filed by eiger....@gmail.com

---

The comparable interface should require implementation of the comparison operators. Given that Dart allows operator overloading, it is far more intuitive to write something along the lines of...

String a = 'aaa';
String b = 'bbb';

if (a < b) {
    print ('Hooray for operators!');
}

...than:

String a = 'aaa';
String b = 'bbb';

if ( a.compareTo(b) < 0) {
    // Whatever else.
}

This is not a huge deal, but to borrow a phrase from the Haskell wiki, it lowers the "semantic gap between the programmer's intention and the language".

[DartBot]

This comment was originally written by fealls...@gmail.com

---

I have to agree, since you also note in Dart's documentation that "No more someString.equals("something").", how about no "a.compareTo(b)"? It doesn't make any sense.

[DartBot]

This comment was originally written by jat@google.com

---

One complication is you would need to define <, >, >=, and <= -- plus you have to worry about inconsistencies with ==/!=. There are a few ways that could be handled -- for example, if a class implements Comparable, the compiler/VM could synthesize the rest if they weren't defined (you could still cause inconsistent behavior by defining them and doing so inconsistently).

---

Removed Type-Defect label.
Added Type-Enhancement label.

[DartBot]

This comment was originally written by sanxi...@gmail.com

---

I think how Python does this, [http://www.python.org/dev/peps/pep-0207/ PEP 207: Rich Comparisons], is relevant here.

[DartBot]

This comment was originally written by eiger.r...@gmail.com

---

@ jat:

It's been awhile since I've been in a university math course, but wouldn't defining less than and equals be enough to synthesize the remaining operators? Are there any cases where something is not less than and not equals, yet it would be incorrect to infer that it's greater?

Also, as far as causing inconsistent behavior by defining inconsistently - wouldn't it be the same with implementing a compareTo method? What's to prevent me from always returning a -1 from compareTo, regardless of value?

The advantage of implementing the operators is that it's far more clear what the logic is being expressed. If I say that string a compared to string b is -1, that's semantically meaningless. As far as I knew, the ONLY reason Java went this route is that there is no operator overloading.

C'mon, if it's just sacred cattle, let's slaughter it. =)

[DartBot]

This comment was originally written by mndri...@gmail.com

---

If interfaces allowed for default method implementations, Comparable operators could be handled something like this:

interface Comparable {
  int compareTo(Comparable other);
  bool operator < (Comparable other) => compareTo(other) < 0;
  bool operator <= (Comparable other) => compareTo(other) <= 0;
  bool operator > (Comparable other) => compareTo(other) > 0;
  bool operator >= (Comparable other) => compareTo(other) >= 0;
  ...
}

This is effectively the same as having the compiler "synthesize the rest", but gives the same tool to the programmer for use in other circumstances. In some ways, this proposal is similar to that suggested in issue #33

[DartBot]

This comment was originally written by jat@google.com

---

Inheriting implementation from an interface seems kind of tricky -- how do you avoid the typical multiple-inheritance problem? For example:

class Foo { bool foo() => ... }
interface Int1 { bool foo() => ... }
interface Int2 { bool foo() => ... }

class Bar extends Foo implements Int1, Int2 {...}

Which foo() does Bar get? What if there is an intermediate superclass between Foo and Bar? This can certainly be solved, but I wonder if there are going to implications from this.

It seems like mixins might be a safer approach.

---

Added Area-Language label.

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Added Triaged label.

[DartBot]

This comment was originally written by benl@google.com

---

In response to #­4, you could even do it all with just <.

a == b -> !(a < b) && !(b < a);
a != b -> !(a == b)
a > b -> b < a;

and so on...

[gbracha]

Removed Area-Language label.
Added Area-Library label.

[floitschG]

We would have liked not to have a special "compareTo" method, but unfortunately doubles make this impossible.

NaN == NaN // false
NaN.compareTo(NaN) // 0
NaN > Infinity // false
NaN < Infinity // false
NaN.compareTo(Infinity) // > 0
-0.0 == 0.0 // true
(-0.0).compareTo(0.0) // < 0

compareTo must be reflexive, antisymmetric and transitive. '<' thus doesn't fit the bill...

Alternatively one could have a a.isLower(b) (or similar) which would avoid up to two comparisons for the common 'if (a.compareTo(b) < 0)...' case.

---

Added WontFix label.

[DartBot]

This comment was originally written by jat@google.com

---

Right, but the comparison operators can be implemented in terms of compareTo, if we add something like mixins Comparable can provide default implementations of them, so if you implement compareTo you get all the rest for free.

[DartBot]

This comment was originally written by boris.moeb...@gmail.com

---

@floitsch
looks to me like sacrificing a well working solution in favour of a very academic case.
NaN > Infinity -> false may lead to the same delusion as NaN > Infinity = true.
I don't see why the latter is worse in real cases. But I see a problem if a, b claim to be comparable, but a < b gives me an error.
By the way Ruby and Swift don't seem to have a problem with this behavior.

[DartBot]

This comment was originally written by dha...@google.com

---

So this won't be fixed because Comparable must be able to handle partial orderings, and adding those comparison operators breaks that. Right?

double.compareTo already produces a total ordering, though, and it considers NaN to be greater than +Inf. So it would be no more broken as long as the Comparable interface's operators were overridden by the ones defined on double.

As an alternative, if Comparable.compareTo could return NaN, then double.compareTo could produce the right results -- and then Comparable's comparison operators would produce the right results too.

So I'm not sure what the issue is.