Comparator

[Dan Smith]

I think we have a good handle on what the feature request looks like, which is much as you describe.

To give you a sense of why defining the expected behavior is not trivial or clear-cut:

class C<S,T extends Serializable> {
  public C<S,T> m(S arg) { System.out.println("m #1"); return this; }
  public C<S,T> m(T arg) { System.out.println("m #2"); return this; }
}

C<String, Integer> c1 = new C<>().m("abc");
C<Integer, String> c2 = new C<>().m("abc");
C<Number, Integer> c3 = new C<>().m(23);
C<Integer, Number> c4 = new C<>().m(23);

What gets printed in each case?  How can the compiler decide which method is applicable, or which is more specific, before it knows what S and T represent?

Some fundamental principles that we are hesitant to break:
- Explicitly inserting type arguments that were inferred doesn't change program behavior.
- Overload resolution choices are context-independent.

A viable alternative is to simply give up in these situations -- chained inference just won't work for some overloaded methods.  But that's more ad hoc behavior, and there's not an obvious answer for where the "this is too hard" line should be drawn.

Again, we are considering it, given its usefulness to the API effort, but, realistically, it is late and this is a nebulous design space -- not the ideal for late inclusion.

—Dan