Question

Imagine this code:

class Foo {
  println("in Foo")

  def foo(a: Int) = a + 1
}

Now, if we invoke:

new Foo().foo _

instance of class Foo will get created, as expected:

in Foo
res0: (Int) => Int = <function1>

However, if we invoke this:

new Foo().foo(_)

Foo’s constructor will not get called:

res1: (Int) => Int = <function1>

If we then say:

res1(7)

that is when Foo gets instantiated:

in Foo
res2: Int = 8

Why does Eta expansion versus partial function application make a difference in class instantiation?

Answer 1

Boy, that’s a subtle one, but as far as I can tell it’s following the Scala spec completely. I’ll quote from version 2.9 of the spec.

For your first example: as you rightly say, you are seeing eta expansion through a special case of a Method Value (§6.7):

The expression e _ is well-formed if e is of method type or if e is a call-by-name parameter. If e is a method with parameters, e _ represents e converted to a function type by eta expansion.

The algorithm for eta expansion is given in §6.26.5 which you can follow to give the following replacement for the expression new Foo().x1 _:

{
  val x1 = new Foo();
  (y1: Int) => x1.(y1);
}

This implies that when eta expansion is being used, all sub-expressions are evaluated at the point where the conversion takes place (if I’ve understood the meaning of the phrase “maximal sub-expression” correctly) and the final expression is the creation of an anonymous function.

In your second example, those extra parentheses mean that the compiler will look at §6.23 (specifically, “Placeholder Syntax for Anonymous Functions) and create an anonymous function directly.

An expression (of syntactic category Expr) may contain embedded underscore symbols _ at places where identifiers are legal. Such an expression represents an anonymous function where subsequent occurrences of underscores denote successive parameters.

In that case, and following the algorithm in that section, your expression ends up being this:

(x1: Int) => new Foo().foo(x1)

The difference is subtle and, as explained very well by @Antoras, only actually shows in the presence of side-effecting code.

Note that there is a bugfix under way for the case involving call-by-name code blocks (see, for example, this question, this bug and this bug).

Postscript: In both cases, the anonymous function (x1:Int) => toto gets expanded to

new scala.Function1[Int, Int] {
  def apply(x1: Int): Int = toto
}