Overload resolution simplification

[Remi Forax]

On 08/11/2013 09:25 PM, Brian Goetz wrote:
>>> What makes you think the goal is encouraging explicit lambdas?
>>
>> Overloads are part of the java legacy. Ignoring them and you will see
>> enterprise guidelines saying that only explicit lambdas should be used.
>> Otherwise, it will break when someone will add an overload.
>
> Overloads are part of the legacy, but the number of genuine SAM-SAM 
> conflicts with existing APIs are pretty small -- I think 
> Executor.submit() is the #1 case, and there are only a handful of others.
>
> What we're trying to discourage is new, designed-for-lambdas APIs from 
> getting out of hand with overloads.  Overloading and type inference 
> work against each other, so if you want to design an API for type 
> inference, you need to dial back on the overloading. (Which we've 
> gradually done throughout the course of designing the java.util.stream 
> API, for a host of reasons.)
>
> So:
>  - For new APIs, go easier on the overloading when there are possible 
> SAM conflicts;
>  - For old APIs that have such conflicts, go explicit.
>
> Maurizio's latest patch also includes a lint warning for overloads 
> that are asking for trouble, so hopefully API designers will have a 
> way of catching those early.
>

Here, we re talking about lambdas and I think I mostly agree,
but we have the same issue with method reference but no way to go explicit.

Rémi