hg: lambda/lambda/langtools: Next round of implementation reflecting the latest 'State of the Lambda' draft; implemented features are:

[maurizio cimadamore]

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. Therefore it's a compile-time error (JLS 3rd 
15.12.2.5). Same as:

void m(A a) { ... } //A and B are unrelated
void m(B b) { ... }

m(null); //ambiguous

Maurizio