JSR 335 Lambda Specification, 0.6.0

[Dan Smith]

On Dec 10, 2012, at 5:01 PM, Remi Forax <forax at univ-mlv.fr> wrote:

>>> Section 18.2.1.3
>>> I'm lost here. Why do you erase the type of the method reference considering it as a lambda without parameter types ??
>> Not sure what you mean.  There's no erasure in 18.2.1.3.
>> 
>> As the discussion points out, the handling of method references mimics both of the previous two areas you asked about: first, like an implicitly-typed lambda, we can't resolve a method reference with inference variables in the parameter types; second, like a nested method invocation, we can't use its target type if the target contains inference variables.
>> 
>> Both of our new inference strategies will come into play here.
> 
> Erasure was not the best term here.
> Suppose we have
> class MyClass {
>  public int myMethod(int t) { ... }
>  public long myMethod(long t) { ... }
> }
> 
> The question is why do you want to translate System.out.println(MyClass::myMethod) to
> System.out.println(e -> MyClass.myMethod(e)) instead of translating it into
> System.out.println(int e -> MyClass.myMethod(e)) or System.out.println(long e -> MyClass.myMethod(e)).
> 
> the overloads of myMethod will give you all the combination that are possible, you have to see if there are applicable
> and then try to find the most specific one.

I think I still might be missing your point.

If you're talking about the process we use to disambiguate between 'myMethod' candidates, we decide which ones are applicable based on the target type.  Your example ('System.out.println') doesn't have a functional interface target, so it would be an error.

If the target had parameter type 'long' or 'Long', then only the 'long' version of 'myMethod' would be applicable.

If the target had parameter type 'int', 'Integer', 'short', etc., then both the 'int' and the 'long' versions of 'myMethod' would be applicable, and we'd use the most-specific analysis to pick one (the 'int' version).

If the target had a to-be-inferred parameter type, then the resolution would depend on how that parameter type is ultimately inferred.  It would be premature to try to resolve 'myMethod' before we resolve the target parameter type.  (Otherwise, the answer we get during inference could be different than the answer we get after inference, and that's never a good thing.)

It _is_ safe to eagerly resolve the method reference if there is only one potentially-applicable method.  That's something we're considering.  It would avoid some ambiguity errors and also provide extra information to inference (e.g., we could get constraints on the target return type from the method reference return before resolving inference vars in the target parameter types).

—Dan