Type inference of parameters

[maurizio cimadamore]

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 
following:

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); });

Maurizio

[1] - 
http://blogs.msdn.com/b/ericlippert/archive/2007/03/26/lambda-expressions-vs-anonymous-methods-part-four.aspx