On Dec 27, 2012, at 2:13 PM, Andreas Rossberg <[email protected]> wrote:
>>> 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').
>>
>> Can you prove this? (Informally is fine, of course!) I mean, can you prove
>> that it can only affect buggy programs?
>
> Well, I think it's fairly obvious. Clearly, once the
> assignment/initialization "x = e" has been (successfully) executed, there is
> no observable difference in the remainder of the program. Before that
> (including while evaluating e itself), accessing x always leads to a TDZ
> exception in the first form. So the only way it can not throw is if stmt and
> e do not access x, in which case the both forms are equivalent.
That doesn't prove that it was a *bug*. That's a question about the
programmer's intention. In fact, I don't think you can. For example, I
mentioned let-binding at the bottom:
{
console.log(x);
let x;
}
It the programmer intended that to print undefined, then TDZ would break the
program. Before you accuse me of circularity, it's *TDZ* that doesn't have
JavaScript historical precedent on its side. *You're* the one claiming that
programs that ran without error would always be buggy.
Here's what it comes down to. Above all, I want let to succeed. The absolute,
#1, by-far-most-important feature of let is that it's block scoped. TDZ, while
clearly adding the bonus of helping catch bugs, adds several risks:
- possible performance issues
- possibly rejecting non-buggy programs based on existing JavaScript
programming styles
Are those risks worth taking? Can we prove that they won't sink let? "It's
fairly obvious" doesn't give me a lot of confidence, I'm afraid.
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
