Overload resolution simplification

[Maurizio Cimadamore]

On 16/08/13 12:08, Stephen Colebourne wrote:
> 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?
That was me being lazy and not wanting to declare another interface just 
for the purpose of the overload; I should have added a note.
>
> 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.

Certainly doable - but subject to the problem of overload being 
dependent on errors in lambda that have been discussed elsewhere.

Maurizio

> WDYT?
> Stephen