Overload resolution simplification

[Stephen Colebourne]

On 16 August 2013 11:16, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> interface Function<X, Y> {
>    Y m(X x)
> }
>
> m(Function<String, Integer> f)
> m(Function<Integer, Integer> f)

Surely, this won't compile due to erasure?

The case I'm most concerned about is:

<T, U> Comparator<T> comparing(Function<T, U> f)
<T> Comparator<T> comparing(ToIntFunction<T> f)
<T> Comparator<T> comparing(ToLongFunction<T> f)
<T> Comparator<T> comparing(ToDoubleFunction<T> f)

comparing( s -> s.length());

In situations like this, it will certainly be easier for the
compiler/library author to choose disambiguation names. But with
different names, users will fall into the trap of using the object
based method with primitives and get worse performance.

A concept I don't think I've seen dicussed, would a strategy favouring
primitives help?

If there are a set of same arity overloads, then do not treat them
equally. Have a fixed order to try:
return type of boolean
return type of int
return type of long
return type of double
return type of anything else

If the check succeeds at a level, then that is chosen, even if other
levels might have passed. There is a combinatorial element
(essentially backtracking), but it is less pronounced. Note that two
overloads with int return type, for example, would still not be
resolvable.
WDYT?
Stephen