int doesn't extend Comparable<int>

[znjameswu]

This is an old issue since Dart 1 and doesn't seem to have been fixed. #8741

This behavior is preventing the below API patterns from being efficiently implemented.

extension ListExtension<T> on List<T> {
  void sortBy<T2 extends Comparable<T2>>(T2 Function(T element) f) {
    this.sort((a, b) => f(a).compareTo(f(b)));
  }
}

Trying to invoke this function

[1].sortBy((x) => x);

will cause error: int doesn't extend Comparable<int>

We need to change generics parameter to num at every invocation site.

[1].sortBy<num>((x) => x);

[lrhn]

The behavior is unfortunate, but not easily correctible.
Dart's int implements num which implements Comparable<num>. That means that int can't also implement Comparable<int>. A Dart 2 type can only implement one version of a generic interface.
Sometimes type inference trips over this, and it fails to recognize that it can choose T2 a num in the example given here and still work successfully. Maybe improving type inference could help, but at the risk of potentially getting worse results in other cases.

Since Comparable is actually a contravariant interface, maybe adding variance annotations can make a difference. Probably not. I think that with proper variance annotations, we can let a subclass implement a more specialized version of a covariant interface, and a more general version of a contravariant interface, but here we need a more specialized version of a contravariant interface.

[eernstg]

If we do make the type argument of Comparable contravariant (that is, if it isn't too much of a breaking change),

class Comparable<in T> {...}

then int <: Comparable<num> <: Comparable<int>, so inference can succeed as [1].sortBy<int>((x) => x);, which would make the example work.

[agrapine]

Yep. This is quite annoying.

[mverver-google]

I regularly run into this problem with Int64 from the fixnum package. This case is interesting because the workaround of explicitly specifying the type argument doesn't work.

The class hierarchy is as follows:

 abstract class IntX implements Comparable<Object> {}
 class Int32 implements IntX {}
 class Int64 implements IntX {}

IntX implements Comparable<object> because e.g. Int64.compareTo() can do a value comparison against Int64, Int32 or int, and Object is the common supertype. But this means that it's impossible to use methods like sortBy() with Int64 even when explicitly specifying the type argument, because IntX doesn't implement Comparable<IntX>, and Object doesn't implement Comparable<Object>.

If Comparable was considered contravariant, that would solve this problem.

P.S. I think this a design mistake in the fixnum package. IntX should implement Comparable<IntX>, which would still allow the method signature to be int compareTo(Object) to support comparison against integers. Maybe I'll file a separate bug about it, though it's probably impossible to fix now without breaking a bunch of existing code.

[mverver-google]

Another solution would be to allow multiple type constraints on a parameter, e.g. like this:

void sortBy<C, T2 extends C & Comparable<C>>(T2 Function(T element) f)

Currently this isn't supported by Dart, as discussed in Issue 1152.

For completeness sake, I'll point out that in Java the problem can be solved with a lower bounded wildcard:

void sortBy<T2 extends Comparable<? super T2>>(T2 Function(T element) f)

Java uses wildcards extensively instead of supporting covariant/contravariant typing. Java's system is more flexible and more sound than the Dart's (which assumes all generic types are covariant, which is nonsense of course), though it leads to more verbose type signatures. I suspect the Dart team would prefer to label types explicitly as covariant/contravariant like Erik suggested above, even if it's less flexible.

[eseidel]

I think an easy solution may just be to mention this gotcha in the docs of sortedBy or wherever else this is easy to trip.

Here is a dartpad example:

import 'package:collection/collection.dart';

class Foo {
  Foo(this.value);
  
  int value;
  
  String toString() => value.toString();
}

void main() {
  final a = <Foo>[Foo(2), Foo(5), Foo(3)];

  // final b = a.sortedBy((f) => f.value);
  // Will fail with:
  //   lib/main.dart:13:15:
  // Error: Inferred type argument 'int' doesn't conform to the bound 'Comparable<K>' of the type variable 'K' on 'IterableExtension|sortedBy'.
  //  - 'Comparable' is from 'dart:core'.
  //   final b = a.sortedBy((f) => f.value);
  //               ^
  // /app/local_pub_cache/hosted/pub.dev/collection-1.17.2/lib/src/iterable_extensions.dart:65:20:
  // Info: This is the type variable whose bound isn't conformed to.
  //   List<T> sortedBy<K extends Comparable<K>>(K Function(T element) keyOf) {
  //                    ^
  // Error: Compilation failed.
  
  // final b = a.sortedBy<int>((f) => f.value);
  // Will fail with:
  //   lib/main.dart:25:18:
  // Error: Type argument 'int' doesn't conform to the bound 'Comparable<K>' of the type variable 'K' on 'IterableExtension|sortedBy'.
  //  - 'Comparable' is from 'dart:core'.
  //      final b = a.sortedBy<int>((f) => f.value);
  //                  ^
  // /app/local_pub_cache/hosted/pub.dev/collection-1.17.2/lib/src/iterable_extensions.dart:65:20:
  // Info: This is the type variable whose bound isn't conformed to.
  //   List<T> sortedBy<K extends Comparable<K>>(K Function(T element) keyOf) {
  //                    ^
  // Error: Compilation failed.

  // So you have to do:
  final b = a.sortedBy<num>((f) => f.value);
  // Or casting also works:
  // final b = a.sortedBy((f) => f.value as num);

  print(b);
}

[natebosch]

@bwilkerson - would it be feasible to specialize the "Couldn't infer parameter" message in the case of Comparable<int>?

This could save us from having to add a warning about this in every method that uses <T extends Comparable<T>>.