Can't manipulate loop indices when closure is present

[TrevorBurnham]

for x, index in [1, 2, 3]
  console.log index
  index++

gives you

0
2

but, if you define a function within the loop,

for x, index in [1, 2, 3]
  func = ->
  console.log index
  index++

gives you

0
1
2

because the code from the loop is moved to a function, making it impossible to modify the original index.

Surely this behavior needs to be made consistent? The simplest solution would be to make loop indices always be immutable, by having the declared index variable always be a copy of the true index variable. The other solution, making loop indices consistently mutable, would be achievable either through a tricky set of returns, or by moving _fn inside of the loop and not passing index as an argument.

[michaelficarra]

These are the current proposals to fix this inconsistency:

• https://gist.github.com/746847
• https://gist.github.com/746729

Notice that this will make the loop index immutable between iterations and mutable within them. This was intentional.

jashkenas notes that modifying the loop index to change program flow is common and actually used in the compiler itself. Loops like this will have to be rewritten as a while, where it is understood that they do their own flow management. When using list comprehensions and for loops, the language handles the iterator for you. This way, when inspecting a statement in the loop body, one will always know what to expect for the next iterator value without inspecting the rest of the loop body.

[TrevorBurnham]

Yes, as I said, making loop indices consistently immutable would be easy. Making them consistently mutable would be slightly harder (let's see... end _fn with return index and compile every continue into return index instead of plain return). I'm happy either way.

[jashkenas]

I think that the behavior in this ticket shouldn't be changed, for the same reason as #954. The dual nature of for/each is how CoffeeScript loops currently work, providing safe block scope if you're using the loop to generate a function.

[michaelficarra]

I think that if we don't decide to change this behaviour now, one of two things will happen:

1. We will be looking back at these one day when coffeescript has matured more saying, "what were we thinking?" (likely)
2. We will see our users come to rely on these broken feature so much so that they demand it stay in the language (unlikely, but it's happened before)

If you were asked what the expected behaviour difference was between Trevor's examples, would you say that there was supposed to be any at all? Because I wouldn't. That's not a feature of a great language like coffeescript.

[TrevorBurnham]

I'm with Michael; the implicit "dual nature" of loops is very confusing, and not worthy of CoffeeScript's 1.0 release. I've raised issue 959 to discuss removing the safe block scope feature.

[jashkenas]

Thanks for wrapping all of this up in #959, Trevor. Closing this ticket in favor of that one.