Overload resolution simplification

[Zhong Yu]

On Fri, Aug 16, 2013 at 6:22 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> 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.

Once the type of lambda parameter is fixed, there is only one
interpretation of the lambda body; the body must compile.

>
> Maurizio
>
>> WDYT?
>> Stephen
>
>