Hello Maurizio,
I played a little with the latest prototype and I must say that for simple cases that I tried, the target typing inferation in combination with overloaded methods (with function types or with SAMs) works very intuitively (even though it is unspecified).
Nevertheless, I stumbled across an inconsistency which might be a bug. The following code:
package closures;
public class Closures
{
public static #int() twice(final int value)
{
return #{ value + value };
}
public static #int() twice(final #int() func)
{
return #{ func.() + func.() };
}
public static void main(String[] args)
{
System.out.println(twice(22).());
#int() fortyFour = twice(#{22});
System.out.println(fortyFour.());
//System.out.println(twice(#{22}).());
}
}
...prints:
44
44
but if the last line is uncommented, I get the following compile-time error:
Closures.java:22: incompatible types; the target type of a lambda conversion must be an abstract class/interface
System.out.println(twice(#{22}).());
^
required: Object
found: #int()
1 error
Regards, Peter
On 07/23/10, maurizio cimadamore wrote:
> On 23/07/2010 20:34, Neal Gafter wrote:
> > On Fri, Jul 23, 2010 at 12:12 PM, maurizio cimadamore
> > <maurizio.cimadamore at oracle.com
> > <mailto:maurizio.cimadamore at oracle.com>> wrote:
> >
> > On 23/07/2010 19:46, Neal Gafter wrote:
> >> On Fri, Jul 23, 2010 at 11:17 AM, maurizio cimadamore
> >> <maurizio.cimadamore at oracle.com
> >> <mailto:maurizio.cimadamore at oracle.com>> wrote:
> >>
> >> I cannot tell from the specification nor from the test cases
> >> provided. Is the invocation of toString() qualified (by an
> >> anonymous subtype of S1) in the generated bytecode as
> >> required by the JLS? The comment in TargetType01 is
> >> mysterious ("ambiguity here - the compiler does not try all
> >> the combinations!"): this code would be ambiguous whether or
> >> not the compiler is required to "try all combinations".
> >> You are right, +(String,String) would still be a valid
> >> expression; I will update the test so that one candidate is
> >> Func<Integer, Integer> and the other one is
> >> Func<DontUseMeInABinaryExpression,
> >> DontUseMeInABinaryExpression> ;-)
> >>
> >>
> >> Sounds good. Then the obvious question is: by what language rule
> >> would the invocation be ambiguous?
> > so, you have two methods M1 and M2. Both are applicable given a
> > set of actual argument types A1, A2 ... An, by method invocation
> > conversion. Unfortunately neither M1 is more specific than M2, nor
> > M2 is more sepcific than M1.
> >
> >
> > Except in this case the "actual argument types" may be lambda
> > expressions, the return type and thrown exceptions of which are
> > necessary for determining if the method is applicable or not. But
> > those can only be computed by performing semantic analysis on the
> > lambda body, which is what you said you weren't going to do. So how
> > *are* you going to determine which methods are applicable?
> >
> As I said in my earlier mail, the compiler uses (among the other things)
> the return type/thrown types inferred from the body of the lambda
> expression. As you can imagine the actual scheme is quite complex as
> there are cases in which such types might depend on the type of 'this'
> which is not available during overload resolution.
>
> Maurizio
>
>