lambda in result expression of explicitly typed lambda

[Maurizio Cimadamore]

I guess I'm missing the connection with pertinent to applicability 
here... anyway, in your example, the lambda is not pertinent to 
applicability (because, recursively, its nested lambda isn't). This 
means that, when doing overload resolution, the lambda is ignored - but 
this doesn't matter here as there's only one 'foo' method, so the 
compiler picks that as the most specific.

I think your question is more about 'invocation type-inference' which 
happens _after_ overload resolution (when a most specific method has 
already been chosen). In this case, the spec says that an additional 
bunch of constraints should be _set up_ for all arguments that are not 
pertinent to applicability (and hence for your lambda too). This doesn't 
mean that the constraints are immediately evaluated, as the dependency 
analysis in 18.5.2 makes sure that arguments constraints are evaluated 
only when all input type variables have been inferred to something.

Maurizio

On 13/02/15 12:21, Anna Kozlova wrote:
> Maurizio,
>
> My understanding of "pertinent to applicability" was always incomplete. "An explicitly typed lambda expression whose body is an expression that is not pertinent to applicability" when pertinent to applicability is defined for argument expression of a method call. Should the return type of selected functional type be checked if it is a proper type (or that it should not be the type parameter of the method)? Did I missed it in the spec or can this be added there please?
>
> Thanks,
> Anna
>
> -----Original Message-----
> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> Sent: Thursday, February 12, 2015 11:13 PM
> To: Anna Kozlova; compiler-dev at openjdk.java.net
> Subject: Re: lambda in result expression of explicitly typed lambda
>
>
> On 12/02/15 19:51, Anna Kozlova wrote:
>> Hi,
>>
>> Consider the following code:
>>      
>>      {
>>            Supplier<Runnable > x = foo (() ->  () -> {});
>>       }
>>
>>       static <T> Supplier<T> foo(Supplier<T> delegate) {
>>           return null;
>>       }
>>
>> At the applicability check phase I expect B2 to contain <() -> {} -> T>,  and according to 18.2.1 it reduces to false ("If T is not a functional interface type (§9.8), the constraint reduces to false").
>> However 8u40 b23 compiles the code just fine, but why?
> I think it's an issue of timing - i.e. 18.2.1 should not be applied to non-proper types; I believe it should only be applied after you inferred T to be Runnable (form the target) and then incorporated the result into the method target (which then becomes Supplier<Runnable>, and 18.2.1 is happy). The reason as to why 18.2.1 is 'deferred' is buried inside
> 18.5.2 - long story short, the constraint () -> () -> {}  --> Supplier<T> cannot be looked into because it depends on an input inference variable, namely T. Since the constraints formula is not evaluated, 18.2.1 doesn't kick in at this stage.
>
> Maurizio
>> Thank you,
>> Anna
>>
>
> !DSPAM:35,54dd256999801336712104!
>
>