Function conversion (SAM) and ambiguity

[Stefan Schulz]

I'd expect this to be solved like it is currently solved on object type 
ambiguity by casting to the destined SAM.

Stefan

Am 15.12.2009 17:32, schrieb Mahmood Ali:
> Greetings,
>
> I was just wondering how the function conversion semantics interacts
> with method overloading, where overloaded methods accept difference
> SAMs.  Should there be a mechanism to explicitly state which interface
> the closure should be converted to?
>
> For example, suppose you have the following declaration
>
>    interface ThrowingRunnable { void run() throws Throwable; }
>    interface Executor {
>      void execute(Runnable r);
>      void execute(ThrowingRunnable r);
>    }
>
>    Executor e = ...
>    e.execute(#() { doSomething(); })   // ambiguous conversion
>    e.execute(#() { throw new RuntimeException(); }) // still ambiguous
>
> I would propose resolving this ambiguity by:
>   1. Issuing an error where an ambigiouty is found, and
>   2. permitting the abstract class/interface name to appear between #
> and parameters:
>
>      e.execute(#Runnable() { doSomething(); });
>      e.execute(#ThrowingRunnable() { throw new RuntimeException(); });
>
> I realize that that space is reserved for return types in function
> type declarations.
>
> - Mahmood
>
>