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