Scopes & Closures (2e) - Chapter 5 - Confusion around auto-initialisation behaviour of `let` vs `var`

[mkaizad]

Please type "I already searched for this issue": I already searched for this issue

Edition: 2nd

Book Title: Scope & Closures

Chapter: 5

Section Title: Uninitialized Variables (aka, TDZ)

Question:

Would it please be possible to clarify the wording of the callout box that follows the fourth code snippet of the Uninitialized Variables (aka, TDZ) section?

Here is the snippet:

// ..

let studentName;
// or:
// let studentName = undefined;

// ..

studentName = "Suzy";

console.log(studentName);
// Suzy

Here is the callout that follows it:

NOTE:
That's interesting! Recall from earlier, we said that var studentName; is not the same as var studentName = undefined;, but here with let, they behave the same. The difference comes down to the fact that var studentName automatically initializes at the top of the scope, where let studentName does not.

It isn't clear how the code snippet demonstrates that let studentName; and let studentName = undefined; behave the same or how the difference between let and var is due to the fact that a let-declared variable is only initialised when its initialiser expression is evaluated by the parser, whereas a var-declared variable is initialised to undefined as soon as it is created.

Please see Question 1 of this post on SO: https://stackoverflow.com/q/67630555/10841085.

[getify]

I've gone back and re-read the whole part of the chapter in question to try and reconstruct what I was thinking and trying to communicate.

I'll be honest, I agree it's not super perfectly clear. But I also can't really come up with a simple way to cure that concern.

Here's what the note is trying to say (which is expounded upon in surrounding text): a var x statement showing up somewhere in code doesn't do anything there... it doesn't act like a var x = undefined at that point; the = undefined part is implied, but it's implied only at the top of the block. By contrast, a let x showing up somewhere does imply and act like a let x = undefined at that exact point, since the = undefined part is not treated as if it happened at the top of the block.

The problem is, there's not a way to demonstrate this with affirmative code, since a stray let x cannot be repeated in the code block the way a var x can be (and was in an earlier example of that chapter). So the code snippet above the callout note in question is implying things which it cannot actually demonstrate, and the note was trying to connect some of those dots.

You can't really understand that until you've read the surrounding (and especially subsequent) text. So the note ultimately doesn't fully accomplish what I hoped. But I cannot imagine a change to either the snippet or note that would resolve the concern.

I don't want to just remove the note, nor do I want to significantly re-arrange text in this part of the chapter, especially given that this book has been out for a year and a half already.

It happens sometimes that book text cannot be fully linearly laid out, where every single sentence is fully supported by everything that's come before it. Sometimes, you have to understand a concept holistically after reading the whole thing, to connect all the dots. I think that's the case here.

So unfortunately, I think this is just a (minor) deficiency that probably needs to stand as-is.