Strange warning

scala> def sayBye(cb:()=>Unit) = {
| cb()
| }
sayBye: (cb: () => Unit)Unit

scala> def byeStephen():Unit = {println(“Bye Stephen”)}
byeStephen: ()Unit

scala> sayBye(byeStephen)
:14: warning: Eta-expansion of zero-argument method values is deprecated. Did you intend to write byeStephen()?
sayBye(byeStephen)
^
Bye Stephen

scala> sayBye(byeStephen())
:14: error: type mismatch;
found : Unit
required: () => Unit
sayBye(byeStephen())
^

Warning suggests to use byeStephen(). But doing so gives error?

I believe to supply a function as an argument one uses byeStephen _

That is, byeStephen, space, underscore.

byeStephen() is a function call - which is not what you want, and
byeStephen is … well, could be either a variable or function call (under the uniform access principl), which is also not what you want

Andre

On the balance of probabilities, I would imagine that most software engineers would prefer the identifier of a so-called “first-class” function object to be just the function’s name (like it is in Haskell), rather than “function space underscore”.

I think a functions first-class object name should be just it’s name.

Somebody, somewhere, thought that Uniform Access Principle was so cool, that it should trump the obvious, That is sad.

Andre

changes coming in Dotty, see https://github.com/lampepfl/dotty/issues/2570#issuecomment-306202339

or perhaps earlier. Scala 2.14 will try to align with Dotty in various ways; these changes seem like candidates for backporting to 2.14

It’s a compiler bug, fixed in Scala 2.12.5 which comes out any day now. The new warning message recommends () => byeStephen().

It could also recommend byeStephen _ (which no longer produces a spurious warning in 2.12.5), but in general, we’re moving away that syntax; see my previous post in this thread.

1 Like

Well, in this example byeStephen is not a first-class function, it’s a method. If we want to lift it to a first-class function, we use the underscore or the arrow syntax as @SethTisue pointed out.

If Scala is moving towards stricter types, with fewer implicit conversions, then from an engineering point of view I’m all for that.

2 Likes