[makomk]

If I'm following the blog post correctly, let does have effects outside of its lexical scope: it effectively makes the variable even more undefined than a totally non-existent variable. That is, the following code will not throw anything:

    // x has not been defined or initialized anywhere
    console.log(typeof x)

However, if you add a let statement after it like so:

    // x has not been defined or initialized here
    console.log(typeof x)
    let x = "foo";

typeof will fail with an exception, because the let statement changes x from an undefined variable to a new state that isn't even undefined anymore.

[ajanuary]

It's not having an effect outside of its lexical scope. You introduce the let into the same lexical scope as the console.log.

It will also throw an exception every single time. So unless you're adding a variable, and then never testing the code path that hits the new line, you're probably going to catch it pretty early.

[TeMPOraL]

Well, but doesn't let itself create a new implicit scope, from the point of the let statement to the end of the scope the statement is in? It seems to me that here let is indeed acting on things outside of lets own implicit lexical scope.

[ajanuary]

They are in the same lexical scope.

Inside a lexical scope, all matching variable names refer to the same variable. Because they are in the same lexical scope, all instances of the variable name "x" refer to the same variable.

Separate (but related) to this is the concept of where it is valid to dereference variables (this is where my knowledge breaks down - is there an accepted term for this?). Javascript says that for variables declared with "var", it is always valid to dereference them, but it might dereference to "undefined". For variables declared with "let", it is only valid to dereference variables in the lexical scope. In addition to this, it defines a "temporal dead zone", which covers the span between the start of the lexical scope and the "let" declaration. This isn't a novel thing - other languages do it, though they may use different terminology.

It's this "temporal dead zone" that you seem to be referring to when you say it's creating a new implicit scope.

It's still impossible for a let declaration to affect anything outside of its lexical scope. If it's shadowing a variable name in a parent scope, what it can do is stop variable names earlier in the scope from referring to the parent scope and make it refer to the variable in inner scope. This may seem like a problem, but most other languages will do the same thing (C++, Java, C#, Python, Ruby etc.) and I've never seen it be much of an issue.

[umurkontaci]

I understand, but I believe this still happens only within the lexical scope where the variable has been defined with let.

TBH, It doesn't bother me at all. I think I can even go ahead and say the latter makes much more sense. Using the former one is abusing the weaknesses of the language that has come along with it throughout its history.

We have been whining about the bad parts of JavaScript for a long, long time and I think these changes are for the better for all of us.

[TeMPOraL]

> I understand, but I believe this still happens only within the lexical scope where the variable has been defined with let.

Doesn't let itself introduce a new, implicit, scope? Here it seems let acts on things outside its own scope, which seems at least ugly.