On dropping @names

David Herman dherman at mozilla.com
Thu Dec 27 22:10:27 PST 2012


On Dec 27, 2012, at 2:13 PM, Andreas Rossberg <rossberg at google.com> 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



More information about the es-discuss mailing list