Overload resolution simplification
brian.goetz at oracle.com
Sun Aug 11 12:25:59 PDT 2013
>> 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
- For new APIs, go easier on the overloading when there are possible
- 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.
More information about the lambda-spec-experts