Type inference of parameters

maurizio cimadamore maurizio.cimadamore at oracle.com
Wed Jul 7 16:06:30 PDT 2010

On 07/07/2010 18:30, Stephen Colebourne wrote:
> The latest (6 July) lambda document includes type inference of formal
> parameters (section 4). I support this decision.
> Without this, I fear we risk creating something akin to the wide lines
> of generics that are being simplified with the diamond operator. So
> long as a user can choose to write the type if they wish, I suspect
> most users will be happy.
> The exact mechanism for calculating the type inference does seem
> tricky as Neal indicates. I'd want to see more detail on how it would
> work in complex cases around method overloading. Like Neal, I'd want
> type inference to work in all cases (as corner cases are what users
> complain about).
I think an example of problematic overload resolution would be the 

interface SAM1 {
    void m1(Integer n) throws Exception;

interface SAM2 {
    void m2(Integer n);

void call(SAM1 sam) { ... }
void call(SAM2 sam) { ... }

call({ x -> System.out.println(x); });

In the general case, it is not clear how the compiler should attribute 
the lambda body when there is no unique target for the SAM conversion; 
one option would be to do a trial-and-error attribution, as described in 
[1]. Instead of solving a problem by introducing another one (as Josh 
said in a separate post, Java method resolution is one of the most 
complicated parts of the language), we decided to ban this kind of 
type-inference - eventually the user will be able to disambiguate at the 
call site in a very java-ish fashion:

call(SAM1 { x -> System.out.println(x); });


[1] - 

More information about the lambda-dev mailing list