Identifier shadowing in for-comprehensions is only supported in `flatMap`s

In dotc 0.7.0, this compiles,

for {
  x <- List(1, 2, 3)
  x <- List(x + 1)
} yield x

but this does not,

for {
  x <- List(1, 2, 3)
  x = x + 1
} yield x

It gives the errors in the REPL,

<console>:14: error: recursive value x needs type
         x = x + 1
               ^
<console>:14: error: x is already defined as value x
         x = x + 1
         ^

It’s probably an accident of implementation, but it’s very useful for getting safe mutable-like syntax in long chained for-comprehensions, without needing to resort to introducing many different identifier names, provided every generator in the for-comprehension is a flatMap, not a map.

This is a quirk of Scala 2, and it would be nice to remove it in Scala 3.

[LPTK]

I just wanted to add that Scala lacking shadowing of local variable is a huge usability problem IMHO. In functional languages like OCaml, where values are usually immutable, you can do:

let name = getName() in
let name = name |> capitalize in
print_string name

In Scala, you have to come up with silly names that pollute the namespace:

val name = getName()
val nameCap = name.capitalize
println(nameCap)

…and in my experience, this is actually a huge source of mistakes. It is all too easy to write println(name), forgetting about the more recent version of the value, nameCap. This is especially terrible if you introduce the intermediate transformation in the middle of existing code, and you have to find and change all usages of the old version in the rest of the function. Shadowing actually helps users by preventing later code from seeing an obsolete binding.

Now, it’s probably too late to change the scoping rules of Scala, but maybe something can be done to alleviate this usability hazard in a backward-compatible way. How about a syntax like this?

val name = getName()
new val name = name.capitalize
println(name)

Then we can then say that for-comprehension bindings have the semantics of new val shadowing bindings instead of the semantics of simple val bindings (and we can make the desugaring itself actually use new val).

[LPTK]

@Sciss the argument is that inventing new names is hard, so at some point you’re going to use dummy names like name0, name1 etc. which is a big potential for mistakes (it’s easy to leave some reference to name2 instead of name3 somewhere). Moreover, in the motivating example the new variable still conceptually represents the name, even though the type is refined, so there is arguably no reason for picking a different name and polluting the local namespace.

Anyway, at this point I guess it depends on individual preferences. Though I think it’s valuable to remember that ML programmers have been doing this for a long time without problems (AFAIK).