ES4 had let (x = x) ... forms (where ... was an expression or a body), 
but for ES6 we agreed on the temporal dead zone:

   { let x = 'outer'; { /* x throws here */; let x = 'inner'; alert(x); 
} alert(x); }

which will alert 'inner' then 'outer'. There is no way to initialize the 
inner x from the outer. The reason for temporal dead zone is given by 
counterexamples against the alternatives. Quoting from Waldemar Horwant at:

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007807.html

"""
There are four ways to do this:

A1. Lexical dead zone.  References textually prior to a definition in 
the same block are an error.
A2. Lexical window.  References textually prior to a definition in the 
same block go to outer scope.
B1. Temporal dead zone.  References temporally prior to a definition in 
the same block are an error.
B2. Temporal window.  References temporally prior to a definition in the 
same block go to outer scope.

Let's take a look at an example:

let x = "outer";
function g() {return "outer"}

{
   g();
   function f() { ... x ... g ... g() ... }
   f();
   var t = some_runtime_type;
   const x:t = "inner";
   function g() { ... x ... }
   g();
   f();
}

B2 is bad because then the x inside g would sometimes refer to "outer" 
and sometimes to "inner".

A1 and A2 introduce extra complexity but doesn't solve the problem.  
You'd need to come up with a value for x to use in the very first call 
to g().  Furthermore, for A2 whether the window occurred or not would 
also depend on whether something was a function or not; users would be 
surprised that x shows through the window inside f but g doesn't.

That leaves B1, which matches the semantic model (we need to avoid 
referencing variables before we know their types and before we know the 
values of constants).
"""

Raul, you seem to want A2 or possibly B2, I'm not sure which. I hope 
this helps make the case for B1, temporal dead zone.

It may seem unusual compared to languages that do not have closures, or 
that require declarations to come before any closures.

/be

> raul mihaila <mailto:raul.mihaila at gmail.com>
> December 24, 2013 12:10 PM
> Merry Christmas!
>
> Did you consider adding a way for variables to automatically get the 
> value from a variable with the same name from the parent execution 
> context?
>
> (function () {
>     var x = 2;
>     (function () {
>         local x; // x = 2
>         x = 100;
>         x; // x = 100
>
>         local y; // maybe throw since y was not found anywhere
>     })();
>
>     x; // x = 2
> })();
>
> This would be useful when optimizing the code so that the variables 
> are as local as possible. Especially useful with calling functions 
> (multiple times) or working heavily with collections from the outer 
> context in the inner functions.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

ES4 had `let (x = x) ...` forms (where ... was an expression or a body), 
but for ES6 we agreed on the temporal dead zone:

```js
{ let x = 'outer'; { /* x throws here */; let x = 'inner'; alert(x); } alert(x); }
```

which will alert 'inner' then 'outer'. There is no way to initialize the 
inner x from the outer. The reason for temporal dead zone is given by 
counterexamples against the alternatives. Quoting from Waldemar Horwant at https://mail.mozilla.org/pipermail/es-discuss/2008-October/007807.html

---

> There are four ways to do this:

> A1. Lexical dead zone.  References textually prior to a definition in the same block are an error.
> A2. Lexical window.  References textually prior to a definition in the same block go to outer scope.
> B1. Temporal dead zone.  References temporally prior to a definition in the same block are an error.
> B2. Temporal window.  References temporally prior to a definition in the same block go to outer scope.
>
> Let's take a look at an example:
>
> ```js
> let x = "outer";
> function g() {return "outer"}
>
> {
>    g();
>    function f() { ... x ... g ... g() ... }
>    f();
>    var t = some_runtime_type;
>    const x:t = "inner";
>    function g() { ... x ... }
>    g();
>    f();
> }
> ```
> 
> B2 is bad because then the x inside g would sometimes refer to "outer" and sometimes to "inner".
> 
> A1 and A2 introduce extra complexity but doesn't solve the problem.  You'd need to come up with a value for x to use in the very first call to g().  Furthermore, for A2 whether the window occurred or not would also depend on whether something was a function or not; users would be surprised that x shows through the window inside f but g doesn't.
> 
> That leaves B1, which matches the semantic model (we need to avoid referencing variables before we know their types and before we know the values of constants).

---

Raul, you seem to want A2 or possibly B2, I'm not sure which. I hope 
this helps make the case for B1, temporal dead zone.

It may seem unusual compared to languages that do not have closures, or 
that require declarations to come before any closures.