bug icon indicating copy to clipboard operation
bug copied to clipboard

eta expansion and currying should work together better

Open adriaanm opened this issue 6 years ago • 4 comments
trafficstars

Test cases derived from https://github.com/scala/bug/issues/11289:

class Test {
  def akkaResponseTimeLoggingFunction(a: String)(x: Int)(y: Boolean): Unit = ???

  // should compile without expected type
  akkaResponseTimeLoggingFunction("a") _
  akkaResponseTimeLoggingFunction("a")(_)(_)

  // eta-expansion only happens when there's an expected type (TODO: neg test for all of these w/o an expected type)
  akkaResponseTimeLoggingFunction("a") : (Int => Boolean => Unit)
  akkaResponseTimeLoggingFunction("a")(_) : (Int => Boolean => Unit)
  akkaResponseTimeLoggingFunction("a")(_)(_) : ((Int, Boolean) => Unit)

  // TODO what about this?
  akkaResponseTimeLoggingFunction(_)(1)(_)

}

WIP branch: https://github.com/adriaanm/scala/tree/t11291

adriaanm avatar Dec 06 '18 09:12 adriaanm

There was a change in behavior from 2.12.7 -> 2.12.8. Since we're talking about partial-eta expansion with no expected type, I think it was actually a bug in 2.12.7 that akkaResponseTimeLoggingFunction("a")(_) would eta-expand further since there's an additional eta-expansion to be done. This is no longer allowed in 2.12.8. The method value syntax akkaResponseTimeLoggingFunction("a") _ works correctly in both versions.

We do have an issue with akkaResponseTimeLoggingFunction("a")(_)(_), which my wip branch attempts to fix. I don't have time to harden that, but it looks close.

adriaanm avatar Dec 06 '18 09:12 adriaanm

Note that Dotty is fine with eta-expanding with no expected type (and in fact I think the goal is to deprecate _ for eta-expansion), though interestingly it looks like it has troubles with the partial eta-expansion examples here.

smarter avatar Dec 07 '18 01:12 smarter

To repeat part of my comment (just now, before I saw yours) at the original report:

When it comes to getting rid of method value syntax f _, I don't think we can do that until we eta-expand regardless of expected type, which is where the real contention lies. I'm in favor, but others worry eta-expanding so recklessly will hide refactoring mistakes (adding an argument list, and then ending up with a bunch of functions rather than type checker complaints of unapplied methods)

adriaanm avatar Dec 07 '18 09:12 adriaanm

Adriaan should have organized a retreat with team-building exercises if he wanted them to work together better.

som-snytt avatar Feb 19 '24 20:02 som-snytt