Fwd: Overload resolution simplification

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Fri Aug 16 13:40:10 PDT 2013


---------- 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

This is exactly my already proposed scheme.

More information about the lambda-spec-observers mailing list