Does 'let' override a global declaration and throws a ReferenceError?

10
votes

I was going through the Difference between var and let documentation example and was testing that when an undeclared variable is invoked, the global scope automatically provides a declaration for it (that's why the following snippet does not throw an error in any of the variables):

x = 3;
console.log(x);

(function() {
  y=x+39;
})()
console.log(y);

However, when one variable is declared with let after the assignment in the same global scope:

x=3;
let x = 42;
console.log(x);

One of the following errors is thrown:

ReferenceError: x is not defined (Chromium)

ReferenceError: can't access lexical declaration x before initialization (Firefox)

I understand that let does not allow x to hoist, but since it was previously referenced (implying an automatic declaration from the global scope) shouldn't in this case a re-declaration happen?

SyntaxError: Identifierx has already been declared

And therefore the error above thrown?

I also understand that in strict mode the first snippet would throw a ReferenceError, so does this mean that let forces this particular rule of strict mode (all variables need to be declared) upon the global scope?

3
javascriptscopeecmascript-6globallet
let is hoisted as well, you just are accessing it during the temporal dead zone. I don't see what strict mode has to do with this. - Bergi
@Bergi I was not fully aware of the TDZ, I was assuming that a non declared variable would be automatically declared in the global scope (at this time the docs only show a double let declaration). Since accessing a variable before its own let declaration throws a ReferenceError, I thought that a strict-mode-behavior/rule was related, but now I understand that it is due to let hoisting the variable. - CPHPython

3 Answers

2
votes

You're right, it's weird behavior. The reason it's giving those errors is because it thinks you're trying to assign the value 3 to your let variable instead of the global value. As others mentioned, this leads to the temporal deadzone issue with hoisting.

The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated

- Source (ECMAScript 8th edition)

This code shows where placing code causes the TDZ:

// Accessing `x` here before control flow evaluates the `let x` statement
// would throw a ReferenceError due to TDZ.
// console.log(x);

let x = 42;
// From here on, accessing `x` is perfectly fine!
console.log(x);

You can see that wrapping the let inside its own block block fixes it:

x=3;
{
let x = 42;
console.log(x); // 42
}

Alternatively, you can define the global explicitly on the window object:

window.x=3;

let x = 42;
console.log(x);  // 42
3
votes

Did you have a look at the let docs at MDN? They describe a temporal dead zone and errors with let.

ES6 does hoist a let variable to the top of its scope. Differently to var variable, when using let you must not access the variable before it is declared. Doing so fail with a ReferenceError (a.k.a. let's temporal dead zone).

0
votes

As Konstantin A. Magg explained, that's because let variables are hoisted and attempts to reference them before initialization throw (temporal dead zone).

If you don't want this, you can split the code into different scripts:

<script>
x = 3;
console.log(x); // 3
</script>

<script>
let x = 42;
console.log(x); // 42
</script>

Note x = 3 will throw in strict mode.