On 28 December 2012 07:10, David Herman <dher...@mozilla.com> wrote:
> On Dec 27, 2012, at 2:13 PM, Andreas Rossberg <rossb...@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.
>
Hold on. First of all, that example is in neither of the two forms whose
equivalence you were asking about. Second, all I was claiming in reply is
that one of those two forms is necessarily buggy in all cases where the
equivalence does not hold. So the above is no counter example to that.
Instead, it falls into the "weird use case" category that I acknowledged
will always exist, unless you make 'let' _exactly_ like 'var'.
As for TDZ precedent, ES6 will have plenty of "precedent" of other lexical
declaration forms that uniformly have TDZ and would not allow an example
like the above. I think it will be rather difficult to make a convincing
argument that having 'let' behave completely differently from all other
lexical declarations is less harmful and confusing than behaving
differently from 'var' -- which is not a lexical declaration at all, so
does not raise the same expectations.
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.
I think introducing 'let' would actually be rather questionable if it was
(1) almost as error-prone as 'var', and at the same time, (2) had a
semantics that is inconsistent with _both_ 'var' and all other lexical
declarations (which is what you are proposing). (Not to mention
future-proofness.)
Your line of argument is 'let' is not like 'var', thereby people will
probably reject it. While I understand your concern, I do not see any
evidence that TDZ specifically will tip that of. So far, I've only heard
the opposite reaction.
Moreover, if you drive that argument to its logical conclusion then 'let'
should just be 'var'. Don't you think that you are drawing a somewhat
arbitrary line to define what you consider 'var'-like enough?
/Andreas
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
