3 ms·

If you're at all interested in how for loops and scope work in Javascript, Jake Archibald and Surma have a great video on the topic: https://www.youtube.com/wat

If you're at all interested in how for loops and scope work in Javascript, Jake Archibald and Surma have a great video on the topic: https://www.youtube.com/watch?v=Nzokr6Boeaw https://www.youtube.com/watch?v=Nzokr6Boeaw Similar changes were made in newer versions of ES so that the for loop in this article works out of the box, like C#. Slightly off-topic to this article: I wish "do while" loops had the "while" condition in the inner scope, not the outer scope. So many times I have wished that I could access the inner scope... I end up using a while(true) with an if { break; } at the end instead in 99% of cases where a do while could've been the perfect thing...

chrismorgan 4y ago
Except the ECMAScript changes weren’t changes but additions. Anything using the var keyword gets the traditional semantics, anything using let and const gets lexical scoping. As an example: x = []; for (var i of [1, 2, 3]) { x.push(() => i); } x.map(f => f()) == [3, 3, 3] x = []; for (let i of [1, 2, 3]) { x.push(() => i); } x.map(f => f()) == [1, 2, 3] What’s being proposed for Go is instead a breaking change.
- baq 4y ago
  > What’s being proposed for Go is instead a breaking change. given the context, it might actually be a fixing change...
- foldr 4y ago
  >What’s being proposed for Go is instead a breaking change. It sounds like you only get the breaking change in modules that require above a certain version of Go. So this should not break old code. It's perhaps more analogous to the way that "use strict" in JavaScript 'breaks' parsing of octal constants.
  - chrismorgan 4y ago
    Ah, my apologies; I missed that part. (I last used Go a decade ago, long before go.mod.) Then this seems fairly reasonable, given also how rarely things will depend on one way or the other.
- masklinn 4y ago
  > What’s being proposed for Go is instead a breaking change. It’s a breaking change in the same sense that the `”use strict;”` semantics of JS were: it’s not actually a breaking change, because you have to opt in.

chrismorgan 4y ago

Except the ECMAScript changes weren’t changes but additions. Anything using the var keyword gets the traditional semantics, anything using let and const gets lexical scoping. As an example: x = []; for (var i of [1, 2, 3]) { x.push(() => i); } x.map(f => f()) == [3, 3, 3] x = []; for (let i of [1, 2, 3]) { x.push(() => i); } x.map(f => f()) == [1, 2, 3] What’s being proposed for Go is instead a breaking change.

baq 4y ago
> What’s being proposed for Go is instead a breaking change. given the context, it might actually be a fixing change...
foldr 4y ago
>What’s being proposed for Go is instead a breaking change. It sounds like you only get the breaking change in modules that require above a certain version of Go. So this should not break old code. It's perhaps more analogous to the way that "use strict" in JavaScript 'breaks' parsing of octal constants.
- chrismorgan 4y ago
  Ah, my apologies; I missed that part. (I last used Go a decade ago, long before go.mod.) Then this seems fairly reasonable, given also how rarely things will depend on one way or the other.
masklinn 4y ago
> What’s being proposed for Go is instead a breaking change. It’s a breaking change in the same sense that the `”use strict;”` semantics of JS were: it’s not actually a breaking change, because you have to opt in.