eta expansion should not precede empty application

[scabug]

There's no upside to it. Empty application cannot hurt eta expansion, but eta expansion can hurt empty application.

I propose the order in SLS 6.26.2 place "Empty Application" before "Eta Expansion".

scala> def f(): Map[Int, Int] = ???
f: ()Map[Int,Int]

scala> def g: Int => Int = f
<console>:8: error: type mismatch;
 found   : () => Map[Int,Int]
 required: Int => Int
       def g: Int => Int = f
                           ^

scala> def g: Map[Int, Int] = f
g: Map[Int,Int]

scala> class Bippy[A, B](f: A => B)
defined class Bippy

scala> def fn() = Map(1 -> 2)
fn: ()scala.collection.immutable.Map[Int,Int]

scala> new Bippy(fn)
<console>:10: error: type mismatch;
 found   : () => scala.collection.immutable.Map[Int,Int]
 required: ? => ?
              new Bippy(fn)
                        ^

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7187?orig=1
Reporter: @paulp

[scabug]

@xeno-by said:
http://groups.google.com/group/scala-internals/browse_thread/thread/08613a0dc1aa1122

[scabug]

@xeno-by said:
Seems related #6221

[scabug]

@retronym said:
The proposal can do more than make non-compiling code compile; it would change the semantics of:

object Test {
  def foo(): () => String = () => ""
  val f: () => Any = foo
 
  def main(args: Array[String]): Unit = {
    println(f()) // currently, <function0>, would be: ""
  }
}

I would argue that these are saner semantics, but we need to find a compatible path from here to there.

Perhaps we could deprecate and later remove eta expansion when the expected type is Function0. I wonder how much that comes up in the wild.

[scabug]

@retronym said:
Here's what I have in mind. I'll discuss this with Adriaan and Martin when we catch up at ScalaDays: https://github.com/retronym/scala/compare/ticket/7187?expand=1

[scabug]

@retronym said:
For sure we need to turn this off for SAMmy (#9178), but we didn't figure out the right approach for regular functions. I'm still in favour of leaving things in the order they stand, but phasing out type-driven eta expansion to F0. But I need to run an experiment with the community build to see if this is used much in the wild.

[scabug]

@som-snytt said (edited on Apr 23, 2015 4:48:55 PM UTC):
You deemed it puzzling on the other ticket, and in fact I did just briefly propose a puzzler scalapuzzlers/scalapuzzlers.github.com#121 where the charm lay in the method, which was a prefix operator (with empty param list). The OP didn't expect f(v) to behave differently from f(!v). If you keep F0 conversion, but try again with empty application in case of failure, then I'll reopen the puzzler.

[scabug]

@adriaanm said:
(Bumping priority to keep it high enough on my list...)

[scabug]

@demobox said (edited on Apr 27, 2015 1:49:12 PM UTC):
I'd agree that the proposed change would make things saner w.r.t. to alignment between parameterless methods and methods with an empty parameter list, so sounds like a good thing. Just wanted to point out that the description

There's no upside to it. Empty application cannot hurt eta expansion, but eta expansion can hurt empty application.

doesn't seem quite correct. E.g. here's an example (similar to the one @retronym gave in a previous comment) of code that would no longer compile:

class Gate {
  def unary_+(): Gate = this
}
val gate = new Gate
def foo(f: () => Gate) = 1

foo(+gate) // currently compiles but would fail if empty application were applied

[scabug]

@paulp said:
I don't really agree this invalidates that statement. Why would you define unary_+ with parentheses, other than the creation of new puzzlers? Do you really consider it an advantage that the expression +gate might be understood as Function0? I don't.

[scabug]

@demobox said:
> Do you really consider it an advantage that the expression +gate might be understood as Function0? I don't.

[~paulp]: I'd agree with that. My comment wasn't clear: I was only trying to point out that the proposed change could cause existing code to break/fail to compile.

The change itself seems desirable to me too - I don't see the current behaviour as an advantage.

[scabug]

@paulp said:
"could cause existing code to break/fail to compile"

Indeed. However that's true of every nontrivial change and most trivial ones. I intended the statement for a fictional universe in which sane semantics are a priority, and in that universe it doesn't come up that empty application can hurt eta-expansion because when it does it's a bug.

[scabug]

@lrytz said (edited on Aug 11, 2016 9:08:22 AM UTC):
scala/scala#5327

[scabug]

@adriaanm said:
I closed this one too soon -- it's only deprecated for now. We'll complete the change in 2.13

[adriaanm]

Implemented under -Xsource:2.13 in scala/scala#6475

[adriaanm]

Changed my mind -- see scala/scala#7660