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 18:11, Neal Gafter wrote:
> On Fri, Jul 23, 2010 at 8:02 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     On 23/07/10 14:48, Neal Gafter wrote:
>
>         Maurizio-
>
>         The test cases do not illustrate what happens in the presence
>         of overloading.
>
>     These two tests:
>
>     + test/tools/javac/lambda/TargetType01.java (negative test)
>     + test/tools/javac/lambda/TargetType02.java (positive test)
>
>
>     Show an example of target typing with overloading.
>
>           Does the language treat overloaded method resolution and
>         non-overloaded method resolution differently?
>
>     What do you mean?
>
>
> Just what I asked.  For example, what is the type of "this" inside the 
> lambda in TargetType02?
S1<Integer>
> 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> ;-)
> However, it isn't clear from the specification or the test cases what 
> would happen in cases where this comment would be meaningful.
The short story is that the compiler uses all the info it can in order 
to reduce the list of potential candidates in an overloaded method call. 
Such info might include particlly attributed parameter types, inferred 
(from lambda body) thrown/return type, type-parameter bounds (in the 
candidate method), etc. If the list of candidates does not have a 
maximally specific method, then an ambiguity error is issued, as usual. 
The compiler however *does not* perform a trial-and-error attribution 
process in order to further reduce candidates from the list (e.g. 
reasoning of the kind: if this target type applied to the lambda body 
causes attribution errors, then remove the candidate from the list).

Maurizio