← Back to context

Comment by pcthrowaway

19 hours ago

Many mistakes in section 2. The author seems to fundamentally misunderstand block scoping vs lexical scoping, and interactions when deferring execution to the next run of the event loop.

In the first example:

    for (let i = 0; i < 3; i++) {
      setTimeout(() => console.log(i));
    }
    // prints "0 1 2" — as expected
    
    let i = 0;
    for (i = 0; i < 3; i++) {
      setTimeout(() => console.log(i));
    }
    // prints "3 3 3" — what?

i's scope is outside the for loop in the second example, and the setTimeouts execute in the call stack (e.g. the next run of the event loop), after i has finished incrementing in the first event loop iteration

Consider that you'd have the same issue with the older `var` keyword which is lexically scoped

    for (var i = 0; i < 3; i++) {
      setTimeout(() => console.log(i));
    }
    // prints "3 3 3" because i is not block-scoped

If for some reason you really need some work run in the next call stack, and you need to use the value of a variable which is scoped outside the loop and modified inside the loop, you can also define a function (or use an iife) to pass the value of i in the current iteration into (rather than getting the reference of i in the event loop's next call stack)

    let i = 0;
    for (i = 0; i < 3; i++) {
      (
        (x)=>setTimeout(()=>console.log(x))
      )(i)
    }
    // prints 1 2 3

18 comments

pcthrowaway

Reply
IshKebab  17 hours ago

This sort of stuff is very explicit and unsurprising in C++ (and to a lesser extent Rust), but it's always confusing in languages that leave the capturing details implicit. Even Go got bitten by this and it doesn't even JavaScript's broken `var`.

  • sapiogram  17 hours ago

    I don't think it's fair to call Go and Javascript's behavior "implicit", they just always capture variables by reference.

    Rust variable capture is implicit though, but it can't cause the problems described in the article, since mutable references are required to be unique.

    • _old_dude_  16 hours ago

      In JavaScript, a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference.

      I think it's fair to call that semantics "implicit".

      5 replies →

bryanrasmussen  14 hours ago

the argument is about things that are weird, any effect in a language that means you have to stop and think over scoping rules to figure out why it should be that way is obviously "weird" to my understanding of this word.

In short I'm not sure that they have misunderstood the scoping, they have probably understood it fine, they have remarked on the weirdness that different aspects of JavaScript enables.

Certainly with perfect understanding and knowledge of a language that you do not have to think about at all because it is so perfectly remembered nothing would ever be weird, it is the incidental behaviors of the language at time where you have to stop and think hey why is that, oh yeah, scoping rules and timeout in the call stack, damn!

n2d4  15 hours ago

Yes, it's about block scoping — but that doesn't make it less weird. In most languages this doesn't really make sense — a variable is a piece of memory, and a reference refers to it. JavaScript doesn't work like that, and that's weird to many.

What's the mistake that I made there? I just didn't explain why it happens. I briefly mentioned this in the later paragraphs — it makes sense to some people, but not to most.

  • rafram  14 hours ago

    JavaScript does work like that, but `for` creates a new block scope for each iteration, so variables declared with `let` in its initializer are redeclared each time. Some other languages ([1]) just make accessing mutable locals from a closure into a compiler error, which I think is also reasonable. Old-school JavaScript (`var`s) chose the worst-of-both-worlds option.

    [1]: https://stackoverflow.com/q/54340101

  • pcthrowaway  14 hours ago

    OK so for one the title of that section is off:

    > JS loops pretend their variables are captured by value

    This has to do with how for loops work with iterators, but also what `let` means in variable declaration. You talk about 'unrolling a for loop' but what you're doing is 'attempting to express the same loop with while'. Unrolling would look like this;

        // original:
    for (let i = 0; i < 3; i ++) { setTimeout(()=>console.log(i)) }
    // unrolled:
    { let i = 0; setTimeout(()=>console.log(i)) };
    { let i = 1; setTimeout(()=>console.log(i)) };
    { let i = 2; setTimeout(()=>console.log(i)) };

    // original:
    let i = 0;
    for (i = 0; i < 3; i++) { setTimeout(()=>console.log(i)) };
    // unrolled:
    let i = 0;
    { i = 0; setTimeout(()=>console.log(i)); };
    { i = 1; setTimeout(()=>console.log(i)); };
    { i = 2; setTimeout(()=>console.log(i)); };

    Now you can begin to explain what's going wrong in the second example; 'i' is declared with 'let' outside of the block, and this means the callback passed to the setTimeout is placed in the next stack frame, but references i from the outer scope, which is modified by the time the next stack frame is running.

    In the original example, a different 'i' is declared inside each block and the callback passed to setTimeout references the 'i' from its scope, which isn't modified in adjacent blocks. It's confusing that you're making this about how loops work when understanding what the loop is doing is only one part of it; understanding scoping and the event loop are 2 other important pieces here.

    And then if you're going to compare a while loop to a for loop, I think a critical piece is that 'while' loops (as well as 'do .. while') take only expressions in their condition, and loop until the expression is false.

    'for' loops take three-part statements, the first part of which is an initialization assignment (for which 'var' and 'let' work differently), and the second of which is an expression used as the condition. So you can declare a variable with 'let' in the initialization and modify it in the 'afterthought' (the third part of the statement), but it will be treated as if each iteration of the loop is declaring it within the block created for that iteration.

    So yes, there are some 'for' loop semantics that are specific to 'for' loops, but rather than explain that, you appear to be trying to make a point about loops in general that I'm not following.

    I'm not saying the examples won't help people avoid pitfalls with for and while loops, but I do think they'll be unable to generalize any lessons they take away to other situations in JS, since you're not actually explaining the principles of JS at play.

    • n2d4  14 hours ago

      I mentioned that the title makes no sense in the sentence right after it:

      > Yes, the title makes no sense, but you'll see what I mean in just a second.

      And yes, I didn't explain the exact mechanics of the ES spec which make it happen — but I would argue that "variables can be modified until they're out-of-scope" is even more unintuitive than just remembering this edge case. And I'm not trying to be an ECMAScript lawyer with the post, rather I'd just show a bunch of "probably unexpected" behaviors of JavaScript.

sapiogram  17 hours ago

The author's explanation seems perfectly correct to me. Where does he "misunderstand block scoping vs lexical scoping"? By the Wikipedia definition:

> lexical scope is "the portion of source code in which a binding of a name with an entity applies".

...both `let` and `var` are lexically scoped, the scopes are just different.

  • Leszek  17 hours ago

    FWIW, I think the parent meant "function scoping vs lexical scoping" rather than "block scoping vs lexical scoping". You're correct that function scoping is technically a form of lexical scoping (where the scope is the function), but if you want to be _really_ pedantic, the ecma262 considers let/const to be "lexical binding"[0] as opposed to var being a "variable declaration"[1], where the former declares in the "Lexical Environment" while the latter declares in the "Variable Environment". These happen to be the same environment record on function entry.

    [0] https://tc39.es/ecma262/#sec-let-and-const-declarations [1] https://tc39.es/ecma262/#sec-variable-statement

  • masswerk  17 hours ago

    However, there's no notion of the first example operating on a single scope and the latter on three different, individual scopes. Which is why scope ranges and where you declare a variable with `let` matters.