Overload resolution simplification

[Zhong Yu]

On Thu, Aug 15, 2013 at 9:00 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 15/08/13 14:24, Zhong Yu wrote:
>>
>> That is not a reason for Java to reject it too. Java traditionally
>> does inference based on assignment context; it'll be nice to continue
>> to do that even with lambda arguments.
>>
>>> >
>
> Well - that wasn't the point of my email; several posts in this thread were
> of the kind - 'why can't you guys just do what C# does' ?
> I only tried to show that there are similar limitations elsewhere.
>
> I explained at least 3-4 times as to why it is actually a good design choice
> not to allow stuff as Comparator.comparing overload - but somehow the
> message doesn't get across. It's not like we are making something dumber or
> different from what it used to be; it's true Java does inference based on
> target context - but that inference has _never_ affected the outcome of
> overload resolution - which helps overload selection to remain tractable
> (i.e. not NP-hard, to go along with Eric Lippert). We'd like to keep it that
> way. That means sticking with a design principle that guided us in the past
> - but I do understand that much of this stuff is subtle and hard to disgest.
>
> Maurizio

I've been only arguing for the limited overload case where all
overloaded methods must agree upon the parameter types of implicit
lambda arguments. That is a tractable strategy. In your previous
example.
> m(x->g(y->f(...)))
> where m, g, f are overloads.
if m,g,f satisfy the requirement about lambda parameter types, it is
as tractable as
  m( (X x)->g( (Y y)->f(...) ) )
If m,g,f don't satisfy the requirement, fail immediately.

Your other objection is that lambda parameter types may depend on
method type variables; but it seems to me that we can first infer
method type variables from other arguments and assignment target,
after which the lambda parameter types are resolved per method,
therefore we can check whether all methods agree upon lambda parameter
types. This is done before selecting the most specific method.

This process may be too complex for programmers to follow, which is
probably Dan's original point. I don't think people care. Nobody reads
the 40 page long JLS section 15.12, yet people are doing ok based on
intuition. I believe people's intuition can handle the limited
overload capability too; in all examples shown so far, none is
difficult to understand if the method is overloaded and the compiler
accepts the invocation. It is more difficult to understand why
overloading does not work in these cases.

Zhong Yu