45

Possible Duplicate:
Functions vs methods in Scala
What is the difference between def foo = {} and def foo() = {} in Scala?

In scala we can define

def foo():Unit = println ("hello")

or

def foo:Unit = println ("hello")

I know they are not the same but what is the difference, and which should be used when?

If this has been answered before please point me to that link.

Community
  • 1
  • 1
Jus12
  • 17,824
  • 28
  • 99
  • 157
  • @MatthewFarwell I don't think the linked question answers the parens question. – Eugene Yokota Sep 29 '11 at 17:45
  • And see also http://stackoverflow.com/questions/6939908/scala-functions-with-no-arguments – Alexey Romanov Sep 29 '11 at 19:18
  • 1
    Question http://stackoverflow.com/questions/7409502/what-is-the-difference-between-def-foo-and-def-foo-in-scala is exactly the same. – paradigmatic Sep 29 '11 at 19:39
  • From the book programming in scala: The two pairs of definitions are completely equivalent from a client's point of view. The only difference is that field accesses might be slightly faster than method invocations because the field values are pre- computed when the class is initialized, instead of being computed on each method call. On the other hand, the fields require extra memory space in each Element object. So it depends on the usage profile of a class whether an attribute is better represented as a field or method, and that usage profile might change over time. – Adelin Feb 24 '22 at 16:26

1 Answers1

63

A Scala 2.x method of 0-arity can be defined with or without parentheses (). This is used to signal the user that the method has some kind of side-effect (like printing out to std out or destroying data), as opposed to the one without, which can later be implemented as val.

See Programming in Scala:

Such parameterless methods are quite common in Scala. By contrast, methods defined with empty parentheses, such as def height(): Int, are called empty-paren methods. The recommended convention is to use a parameterless method whenever there are no parameters and the method accesses mutable state only by reading fields of the containing object (in particular, it does not change mutable state).

This convention supports the uniform access principle [...]

To summarize, it is encouraged style in Scala to define methods that take no parameters and have no side effects as parameterless methods, i.e., leaving off the empty parentheses. On the other hand, you should never define a method that has side-effects without parentheses, because then invocations of that method would look like a field selection.

Terminology

There are some confusing terminology around 0-arity methods, so I'll create a table here:

Programming in Scala scala/scala jargon
def foo: Int parameterless methods nullary method
def foo(): Int empty-paren methods nilary method

It might sound cool to say "nullary method", but often people say it wrong and the readers will also be confused, so I suggest sticking with parameterless vs empty-paren methods, unless you're on a pull request where people are already using the jargons.

() is no longer optional in Scala 2.13 or 3.0

In The great () insert, Martin Odersky made change to Scala 3 to require () to call a method defined with (). This is documented in Scala 3 Migration Guide as:

Auto-application is the syntax of calling a nullary method without passing an empty argument list.

Note: Migration document gets the term wrong. It should read as:

Auto-application is the syntax of calling a empty-paren (or "nilary") method without passing an empty argument list.

Scala 2.13, followed Scala 3.x and deprecated the auto application of empty-paren methods in Eta-expand 0-arity method if expected type is Function0. A notable exception to this rule is Java-defined methods. We can continue to call Java methods such as toString without ().

Eugene Yokota
  • 94,654
  • 45
  • 215
  • 319
  • Can you expand on the definition of "side-effects"? – Jus12 Sep 29 '11 at 19:50
  • 3
    @Jus12 that will be a whole another question, which you can dig up or see Wikipedia - http://en.wikipedia.org/wiki/Side_effect_(computer_science) – Eugene Yokota Sep 30 '11 at 00:54
  • Very stupid language design – Jian Chen Dec 31 '22 at 06:13
  • "the method accesses mutable state only by reading fields of the containing object (in particular, it does not change mutable state)." - Sounds like you are saying no side effect. "you should never define a method that has side-effects without parentheses," - again sounds you are saying no side effects. In case I have a method that takes no parameters and mutates a class parameter (say appends to a list), what is the suggested way to define that method? – figs_and_nuts Mar 07 '23 at 07:36