`def` vs `val` vs `lazy val` evaluation in Scala

Question

Am I right understanding that

• def is evaluated every time it gets accessed

• lazy val is evaluated once it gets accessed

• val is evaluated once it gets into the execution scope?

Answer 1

Yes, but there is one nice trick: if you have lazy value, and during first time evaluation it will get an exception, next time you'll try to access it will try to re-evaluate itself.

Here is example:

scala> import io.Source
import io.Source

scala> class Test {
     | lazy val foo = Source.fromFile("./bar.txt").getLines
     | }
defined class Test

scala> val baz = new Test
baz: Test = Test@ea5d87

//right now there is no bar.txt

scala> baz.foo
java.io.FileNotFoundException: ./bar.txt (No such file or directory)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:137)
...

// now I've created empty file named bar.txt
// class instance is the same

scala> baz.foo
res2: Iterator[String] = empty iterator

Answer 2

Yes, though for the 3rd one I would say "when that statement is executed", because, for example:

def foo() {
    new {
        val a: Any = sys.error("b is " + b)
        val b: Any = sys.error("a is " + a)
    }
}

This gives "b is null". b is never evaluated and its error is never thrown. But it is in scope as soon as control enters the block.

Answer 3

I would like to explain the differences through the example that i executed in REPL.I believe this simple example is easier to grasp and explains the conceptual differences.

Here,I am creating a val result1, a lazy val result2 and a def result3 each of which has a type String.

A). val

scala> val result1 = {println("hello val"); "returns val"}
hello val
result1: String = returns val

Here, println is executed because the value of result1 has been computed here. So, now result1 will always refer to its value i.e "returns val".

scala> result1
res0: String = returns val

So, now, you can see that result1 now refers to its value. Note that, the println statement is not executed here because the value for result1 has already been computed when it was executed for the first time. So, now onwards, result1 will always return the same value and println statement will never be executed again because the computation for getting the value of result1 has already been performed.

B). lazy val

scala> lazy val result2 = {println("hello lazy val"); "returns lazy val"}
result2: String = <lazy>

As we can see here, the println statement is not executed here and neither the value has been computed. This is the nature of lazyness.

Now, when i refer to the result2 for the first time, println statement will be executed and value will be computed and assigned.

scala> result2
hello lazy val
res1: String = returns lazy val

Now, when i refer to result2 again, this time around, we will only see the value it holds and the println statement wont be executed. From now on, result2 will simply behave like a val and return its cached value all the time.

scala> result2
res2: String = returns lazy val

C). def

In case of def, the result will have to be computed everytime result3 is called. This is also the main reason that we define methods as def in scala because methods has to compute and return a value everytime it is called inside the program.

scala> def result3 = {println("hello def"); "returns def"}
result3: String

scala> result3
hello def
res3: String = returns def

scala> result3
hello def
res4: String = returns def

Answer 4

One good reason for choosing def over val, especially in abstract classes (or in traits that are used to mimic Java's interfaces), is, that you can override a def with a val in subclasses, but not the other way round.

Regarding lazy, there are two things I can see that one should have in mind. The first is that lazy introduces some runtime overhead, but I guess that you would need to benchmark your specific situation to find out whether this actually has a significant impact on the runtime performance. The other problem with lazy is that it possibly delays raising an exception, which might make it harder to reason about your program, because the exception is not thrown upfront but only on first use.

Answer 5

You are correct. For evidence from the specification:

From "3.3.1 Method Types" (for def):

Parameterless methods name expressions that are re-evaluated each time the parameterless method name is referenced.

From "4.1 Value Declarations and Definitions":

A value definition val x : T = e defines x as a name of the value that results from the evaluation of e.

A lazy value definition evaluates its right hand side e the first time the value is accessed.

Answer 6

def defines a method. When you call the method, the method ofcourse runs.

val defines a value (an immutable variable). The assignment expression is evaluated when the value is initialized.

lazy val defines a value with delayed initialization. It will be initialized when it's first used, so the assignment expression will be evaluated then.

Answer 7

A name qualified by def is evaluated by replacing the name and its RHS expression every time the name appears in the program. Therefore, this replacement will be executed every where the name appears in your program.

A name qualified by val is evaluated immediately when control reaches its RHS expression. Therefore, every time the name appears in the expression, it will be seen as the value of this evaluation.

A name qualified by lazy val follows the same policy as that of val qualification with an exception that its RHS will be evaluated only when the control hits the point where the name is used for the first time

Answer 8

Should point out a potential pitfall in regard to usage of val when working with values not known until runtime.

Take, for example, request: HttpServletRequest

If you were to say:

val foo = request accepts "foo"

You would get a null pointer exception as at the point of initialization of the val, request has no foo (would only be know at runtime).

So, depending on the expense of access/calculation, def or lazy val are then appropriate choices for runtime-determined values; that, or a val that is itself an anonymous function which retrieves runtime data (although the latter seems a bit more edge case)