SAM conversion and overload resolution

[Peter Levart]

Although the exact algorithm is currently only specified in the javac sources of lambda prototype, it does quite a good job when experimenting with simple usecases. I was thinking that a refinement might even be better...

The following program does not compile:


public class Closures 
{
  public interface ComparableF { Comparable invoke(); }
  public interface StringF { String invoke(); }

  public static void say(StringF stringFunc) {
    System.out.println("stringFunc says: " + stringFunc.invoke());
  }

  public static void say(ComparableF comparableFunc) {
    System.out.println("comparableFunc says: " + comparableFunc.invoke());
  }

  public static void main(String[] args) 
  {
    say(#{ "Hello" });
  }
}


... javac complains that:

Closures.java:19: reference to say is ambiguous, both method say(StringF) in Closures and method say(ComparableF) in Closures match
    say(#{ "Hello" });
    ^
1 error


With a simple change to the source from:

  public interface StringF { String invoke(); }

to:

  public interface StringF extends ComparableF { String invoke(); }


... the program compiles and prints:

stringFunc says: Hello


... because the standard overload resolution can choose the most specific method.


Now if we defined some kind of "soft-subtype" relationship among SAM types that worked on covariance of SAM return type and contravariance of SAM parameter types, then overload resolution could use this relationship as a last resort to try to disambiguate method resolution. You see that I didn't mention the lambda expression - just the target SAM types. How initial selection of "possible method candidates" is performed can be totaly independent of this "soft-subtype" relationship.


Regards, Peter