<div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div dir="ltr"><div class="gmail_default" style>On 27 December 2012 01:50, David Herman <span dir="ltr"><<a href="mailto:dherman@mozilla.com" target="_blank">dherman@mozilla.com</a>></span> wrote:<br>

</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Dec 11, 2012, at 2:45 AM, Andreas Rossberg <<a href="mailto:rossberg@google.com">rossberg@google.com</a>> wrote:<br>

> The question, then, boils down to what the observation should be: a<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">
> runtime error (aka temporal dead zone) or 'undefined'. Given that<br>
> choice, the former is superior in almost every way, because the latter<br>
> prevents subtle initialisation errors from being caught early, and is<br>
> not an option for most binding forms anyway.<br>
<br>
</div>You only listed good things (which I agree are good) about TDZ, but you don't list its drawbacks. I believe the drawbacks are insurmountable.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Let's start with TDZ-RBA. This semantics is *totally untenable* because it goes against existing practice. Today, you can create a variable that starts out undefined and use that on purpose:<br></blockquote><div><br>

</div><div>I think nobody ever proposed going for this semantics, so we can put that aside quickly. However:</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

    var x;<br>
    if (...) { x = ... }<br>
    if (x === undefined) { ... }<br>
<br>
If you want to use let instead, the === if-condition will throw. You would instead have to write:<br>
<br>
    let x = undefined;<br>
    if (...) { x = ... }<br>
    if (x === undefined) { ... }<br></blockquote><div><br></div><div style>That is not actually true, because AFAICT, "let x" was always understood to be equivalent to "let x = undefined".</div><div style>

<br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">OK, so now let's consider TDZ-UBI. This now means that an initializer is different from an assignment, as you say:<br>


<div class="im"><br>
> They are initialisations, not assignments. The difference, which is<br>
> present in other popular languages as well, is somewhat important,<br>
> especially wrt immutable bindings.<br>
<br>
</div>For `const`, I agree that some form of TDZ is necessary. But `let` is the important, common case. Immutable bindings (`const`) should not be driving the design of `let`. Consistency with `var` is far more important than consistency with `const`.<br>

</blockquote><div><br></div><div style>There is not just 'let' and 'const' in ES6, but more than a handful of declaration forms. Even with everything else not mattering, I think it would be rather confusing if 'let' had a different semantics completely different from all the rest.</div>

<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">And for `let`, making initializers different from assignments breaks a basic assumption about hoisting. For example, it breaks the equivalence between<br>


<br>
    { stmt ... let x = e; stmt' ... }<br>
<br>
and<br>
<br>
    { let x; stmt ... x = e; stmt' ... }<br>
<br>
This is an assumption that has always existed for `var` (mutatis mutantum for the function scope vs block scope). You can move your declarations around by hand and you can write code transformation tools that move declarations around.<br>

</blockquote><div><br></div><div style>As Dominic has pointed out already, this is kind of a circular argument. The only reason you care about this for 'var' is because 'var' is doing this implicitly already. So programmers want to make it explicit for the sake of clarity. TDZ, on the other hand, does not have this implicit widening of life time, so no need to make anything explicit.</div>

<div style><br></div><div style>It's true that with TDZ, there is a difference between the two forms above, but that is irrelevant, because that difference can only be observed for erroneous programs (i.e. where the first version throws, because 'x' is used by 'stmt').</div>

<div style></div></div><br></div><div class="gmail_extra" style>/Andreas</div><div class="gmail_extra" style><br></div></div></div>