Fwd: Overload resolution simplification

[Ali Ebrahimi]

Hi,

---------- Forwarded message ----------
From: Stephen Colebourne <scolebourne at joda.org>
Date: Fri, Aug 16, 2013 at 3:38 PM
Subject: Re: Overload resolution simplification
To: lambda-spec-observers at openjdk.java.net


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?

This is exactly my already proposed scheme.