A bad argument against mutable lexical variables

Been a long time... Anyway, I was reading this proposal for Java closures (well, more or less closures, you know what I mean).

Not much to say about the proposal as a whole. But this...

It is likely that we will not permit capture of mutable local variables. The reason is that idioms like this:

int sum = 0;
list.forEach({ Element e -> sum += e.size(); });

are fundamentally serial; it is quite difficult to write lambda bodies like this that do not have race conditions. Unless we are willing to enforce (preferably statically) that such lambdas not escape their capturing thread, such a feature may likely cause more trouble than it solves.

This strikes me as as a really basically ridiculous argument. Of course it's true, but honestly, in many, many common usages, people will assume serial execution, and they will write code like this:

Map<...> buckets = ...;
list.forEach({ Element e -> buckets.put(foo(e), bar(e)); });

Somehow this is different? And honestly, there's nothing wrong with it! Suggesting that all of a sudden I have to assume that whenever I create an object, its methods might get called on any old arbitrary thread is just bizarre. Programmers already have to manage this today, and if anything, it's clearer with closures rather than less clear. This is one of the silliest arguments I've ever seen against mutable lexical variables.

(And if you think people aren't going to just create the single-element array or generic mutable Cell<T> class or whatever, well... think again.)

If you don't want to allow mutable variable capture because the JVM just doesn't support it and the compiler magic is more trouble (and performance opacity) than it's worth, just say so!