Overload resolution simplification
forax at univ-mlv.fr
Tue Aug 13 14:24:51 PDT 2013
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.)
> - 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.
More information about the lambda-spec-observers