Imported From: https://issues.scala-lang.org/browse/SI-9606?orig=1
Reporter: Mike Slinn (mslinn)
Affected Versions: 2.12.0-M3

@szeiger said:
IMHO not a bug. The inline eta-expansion works because the compiler infers the correct type whereas your explicitly eta-expanded times2b has the wrong type. Compare these:

  vector2.flatMap( _.map(_*2) )
  vector2.flatMap( (_.map(_*2)): (Option[Int] => collection.GenTraversableOnce[Int]) ) // inferred type
  vector2.flatMap( (_.map(_*2)): (Option[Int] => Option[Int]) ) // wrong

An Option\[Int\] => Option\[Int\] cannot be converted to an Option[Int] => GenTraversableOnce[Int] but a (v: Option[Int])Option[Int] can be eta-expanded to that type. The expansion looks something like this (and type-checks successfully, as expected):

  vector2.flatMap( { (x: Option[Int]) => times2a(x) } )

The implicit conversion is applied to the result of the method call, converting an Option[Int] to a GenTraversableOnce[Int].

@dwijnand said (edited on Jan 19, 2016 10:17:23 PM UTC):
While I appreciate the internal technical reasons, particularly learning a bit more about what things are called, is eta-expansion something that a Scala developer that might encounter such a bug should know and understand?

I think there's a bug here IMHO.

Mike Slinn (mslinn) said:
I don't care if this is officially classified as a bug or not. What concerns me is that the a lifted method behaves differently than its FunctionN equivalent. I expect that the inconsistency is unlikely to provide benefit to a user, but is likely to cause frustration.

@szeiger said:
Eta-expansion is in the spec. Leaving aside hygiene and evaluation order it's really just wrapping a method call in a lambda, i.e. f\(m\) becomes f\(x => m\(x\)\). If there is an implicit conversion from the result type of m to the expected result type of the function, it is naturally applied, no special rules required.

If you wrap a function application in another lambda you get the same result:

scala> vector2.flatMap { times2b }
<console>:13: error: type mismatch;
 found   : Option[Int] => Option[Int]
 required: Option[Int] => scala.collection.GenTraversableOnce[?]
       vector2.flatMap { times2b }
                         ^

scala> vector2.flatMap { x => times2b(x) }
res1: scala.collection.immutable.Vector[Int] = Vector(2, 6, 8)

@dwijnand said:
Is the spec something that's expected to be known? I don't mean that as a taunt, I'm genuinely wondering.

@szeiger said:
@dwijnand, my take on this is that most programmers would not have read the spec and you should be able to be productive after taking a course or reading a book that teaches the language. For deciding whether something is a bug in the compiler / standard library, knowledge of the specification is required, of course. In this particular case, it works as specified and the specified behavior is the most natural one I can think of. The resulting interaction of language features may still qualify as a Scala puzzler.

In order to turn this from a bug report into an improvement request you'd have to specify what to change. The most obvious changes would be to either make both cases work by adding an implicit conversion for functions:

// Does not work with current type inference / implicit search rules:
implicit def adaptFunction1[P, R, A](f: P => R)(implicit conv: R => A): (P => A) = (x => conv(f(x)))

Or to forbid both by changing eta expansion to typecheck without a return type. You have the same issue for parameters though, so you can either make the rules inconsistent or forbid that as well, which would in turn prevent you from ever eta-expanding an overloaded method.

I doubt either of those changes would get very far.

Mike Slinn (mslinn) said:
Once again we are left with the message that "Scalac occasionally does weird shit that only the high priests understand".

Over a year ago @odersky said "we want to eliminate some traps that people have found hard in Scala -- so-called puzzlers". Perhaps scalac should recognize specific situations such as this and respond by doing what likely makes most sense to a user, even if it is inconsistent in some more general theoretical sense.

@som-snytt said:

The compiler could emit better advice, or possibly a tool (clippy) could take up the slack.

scala> vs.flatMap(f _)
<console>:14: error: type mismatch;
 found   : () => Option[Int] => Option[Int]
 required: Option[Int] => scala.collection.GenTraversableOnce[?]
       vs.flatMap(f _)
                  ^

scala> vs.flatMap(o => f(o))
res3: scala.collection.immutable.Vector[Int] = Vector(2)

scala> vs.flatMap(f(_))
res4: scala.collection.immutable.Vector[Int] = Vector(2)