A def with a parameter list has a different type than one without a parameter list. It doesn’t matter with a direct call, but if you pass this method as an argument to another method, it will happen.
In the example, if you define your method as follows:
def func1 = { println("Hello"); 1 }
You cannot pass it to this method:
def consume(f: () => Double) = // ...
since he's just Double type, albeit very lazy. On the other hand, this function will work fine:
def func2() = { println("Hello"); 2 }
I'm not saying that this is a clear reason why they did it, but if they have a real reason, they will almost certainly be attached to the type.
EDIT:
The difference between them in practical terms basically comes down to where they can be used.
The call-by-value element can only be used in the parameter list for a function / method (afaik). Since it can only be passed in the parameter list, it cannot be stored in a variable and used in several places (without changing it to an explicit instance of T ).
And, as you can see here, they are not interchangeable as such:
scala> def f(s: => String) { println(s) } f: (s: => String)Unit scala> def s1 = () => { "Hello" } s1: () => String scala> f(s1) <console>:10: error: type mismatch; found : () => String required: String f(s1) ^
So imagine that I wanted to save an array of callbacks that users pass me .. I can't use => T here:
scala> val a: Array[=> Int] = Array() <console>:1: error: identifier expected but '=>' found. val a: Array[=> Int] = Array() ^ scala> val a: Array[() => Int] = Array() a: Array[() => Int] = Array()
Therefore, if I want to store such elements and pass them inside, using => T (and keeping it lazily evaluated) is not an option.
I think it’s better not to think about => in => T and () => T as about the same. Hope this helps a bit.