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

[Nathan Bryant]

The usual rules would seem to be appropriate when the parameter type is known. In this case, it is not.

Nathan

-----Original Message-----
From: neal.gafter at gmail.com [mailto:neal.gafter at gmail.com] On Behalf Of Neal Gafter
Sent: Monday, July 26, 2010 2:05 PM
To: Nathan Bryant
Cc: Neal Gafter; Joe Darcy; maurizio.cimadamore at oracle.com; lambda-dev at openjdk.java.net
Subject: Re: hg: lambda/lambda/langtools: Next round of implementation reflecting the latest 'State of the Lambda' draft; implemented features are:

No, it is not ambiguous because one of these methods is more specific
than the other, according to current overload resolution rules.

On Monday, July 26, 2010, Nathan Bryant <nathan.bryant at linkshare.com> wrote:
> Neal Gafter wrote:
>
>> ... I prefer that we define a subtype relation
>> between lambda expressions and object types (SAM types and function
>> types) and use that for overload resolution as usual.  That is the
>> approach that BGGA takes.
>
> Does this mean that the following is always ambiguous?
>
> interface Block<T> {
>         void do(T t);
> }
>
> interface SpecializedBlock<T> extends Block<T> {
> }
>
> class Foo {
> void forEach(Function<T> f) {
> }
>
> void forEach(SpecializedFunction<T> f) {
> }
> }
>
> new Foo().forEach(#(f) {//something});
>
> According to the usual rules, we resolve the call to
> forEach(SpecializedFunction), but in a great many cases this is exactly
> the opposite of what the user would intend.
>