lambda in result expression of explicitly typed lambda

Anna Kozlova anna.kozlova at jetbrains.com
Fri Feb 13 12:21:54 UTC 2015


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!




More information about the compiler-dev mailing list