In fact, when one passes a lazy val: Int where a => Int is required one might actually be surprised that it does compile, as at first glance the types seem to be different. When it does compile, you may think, “What is happening? Is there an implicit conversion? Is one syntactic sugar for the other?”

I submit that allowing one to define a lazy parameter would improve Scala’s readability and useability.

Are there important distinctions between => Int and lazy val i: Int that would preempt such syntax?

This just reminds me that ‘lazy val’ is a bad name and leads to poor assumptions about how best to use it. A better name would have been ‘memoize def’.

Semantically it is a val in that (1) it requires storage for its contents, and (2) it doesn’t change.

Semantically it is lazy in that it isn’t computed until it’s needed.

Memoization of parameterless* immutable/pure defs is maybe semantically equivalent, but why explain a simple two-part concept with four concepts, one of which (memoization) is not exactly simple, and which doesn’t tell the entire story unless you think carefully about implementation?

(* They’re generally not actually parameterless unless they’re useless. The parameters are just passed implicitly e.g. by being part of the object upon which the def is defined. So I don’t know that this concept is simple either.)