method type adaptation: latent tension between eta-expansion vs nullary application nears breaking point with SAM synthesis

[scabug]

If you have a Java interface that could be a SAM:

public interface Foo<A> { public A aye(); }

And you refer to that from a Java interface that need not necessarily be a SAM:

public interface Bar<A> { public Foo<A> foo(); }

And you have a Scala trait that is supposed to give the SAM:

trait Baz[A] { def foo: Foo[A] }

And finally extend that trait and try to supply the SAM by getting it from the Java interface that can give you a SAM:

class Quux[A](bar: Bar[A]) extends Baz[A] { def foo = bar.foo }

you get a most peculiar error message:

found   : Foo[A]
required: A
  def foo = bar.foo

which only makes sense to me if the compiler has decided that it's got to synthesize the Foo SAM from scratch--no other way!--and then decides it's got to have an A to do it (never mind I'm giving it the already-existing SAM).

This only happens with -Xexperimental, and only (as far as I can tell) with this many steps: the original SAM, the Java source that returns a SAM, the trait specifying an SAM, and finally an implementation trying to hand off the Java SAM to the trait's method.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9178?orig=1
Reporter: @Ichoran
Affected Versions: 2.11.5
See #7187

[scabug]

@retronym said (edited on Feb 24, 2015 11:21:18 AM UTC):
Here's another simpler repro that shows the same underlying problem. Notice the unwanted SAM.

% cat sandbox/test.scala
trait Sam { def apply(): Unit }
abstract class Test {
  def foo(): Sam
  val f: Sam = foo /* no parens */
}

% qscalac -Xprint:typer sandbox/test.scala
[[syntax trees at end of                     typer]] // test.scala
package <empty> {
  abstract trait Sam extends scala.AnyRef {
    def apply(): Unit
  };
  abstract class Test extends scala.AnyRef {
    def <init>(): Test = {
      Test.super.<init>();
      ()
    };
    def foo(): Sam;
    private[this] val f: Sam = Test.this.foo();
    <stable> <accessor> def f: Sam = Test.this.f
  }
}

% qscalac -Xprint:typer -Xexperimental sandbox/test.scala
[[syntax trees at end of                     typer]] // test.scala
package <empty> {
  abstract trait Sam extends scala.AnyRef {
    def apply(): Unit
  };
  abstract class Test extends scala.AnyRef {
    def <init>(): Test = {
      Test.super.<init>();
      ()
    };
    def foo(): Sam;
    private[this] val f: Sam = {
      {
        def apply$body(): Unit = {
          Test.this.foo();
          ()
        };
        @SerialVersionUID(value = 0) final class $anonfun extends AnyRef with Sam with Serializable {
          def <init>(): <$anon: Sam> = {
            $anonfun.super.<init>();
            ()
          };
          final override <synthetic> def apply(): Unit = apply$body()
        };
        new $anonfun()
      }
    };
    <stable> <accessor> def f: Sam = Test.this.f
  }
}

In a context that does not allow a method type, when typechecking an expression like qual.foo where foo is a method with a single, empty parameter list, the compiler tries, in order:

• eta expansion, if the expected type if a function type (or a SAM under -Xexperimental)
• applying the expression to an empty parameter list

In these examples, we don't get to the second measure.

Here's a analagous situation with plain-old-functions:

object Test {
  def foo(): () => String = () => ""
  val f: () => Any = foo

  def main(args: Array[String]): Unit = {
    println(f()) // <function0>
  }
}

So even though SAMs are behaving consistently with functions, they introduce a pretty subtle source incompatibility.

I've updated the bug title to reflect the essence of the problem. I'll leave it to @som-snytt to craft a puzzler around this.

[scabug]

@paulp said:
[Insert my usual commentary.]

#7187 "eta expansion should not precede empty application"

Pretty good title on that one too.

[scabug]

@paulp said:
Relevant summary from the scala-internals thread: "I think that if the expression would typecheck through the addition of empty parentheses, that should not be subverted by an unnecessary eta-expansion."

[scabug]

@retronym said (edited on Feb 25, 2015 12:38:09 AM UTC):
I'd be inclined to go further and deprecate eta-expansion given an expected type of Function0, and avoid triggering it with SAM types of the same shape from the outset.

[scabug]

@adriaanm said:
scala/scala#4822