Continuing woes in reading the ES6 spec language

Andreas Rossberg rossberg at google.com
Fri Sep 13 11:09:43 PDT 2013


On 13 September 2013 19:18, Oliver Hunt <oliver at apple.com> wrote:
>
> On Sep 13, 2013, at 9:58 AM, Andreas Rossberg <rossberg at google.com> wrote:
>
>> On 13 September 2013 18:39, Oliver Hunt <oliver at apple.com> wrote:
>>> The problem with temporal dead zones is that they lead to weird behaviour in edge cases, and almost all of them should be syntactically identifiable as errors up front.  The problem is that you can only _almost_ get syntax checked behaviour upfront because eval.
>>
>> There must be a misunderstanding -- eval is not relevant to the issue
>> that TDZ is addressing.  The issue is mutual recursion between
>> bindings that can perform arbitrary (higher-order) computations.  In
>> that situation, it is generally impossible to ensure the absence of
>> errors without a type system.  And even with one, it is tedious to the
>> degree that it is arguably impractical.  So, as long as JavaScript
>> allows that (and I don't see how we can change that), TDZ is the
>> best/only we can do.
>>
>> What "weird edge case" do you have in mind? I cannot imagine anything
>> that isn't even weirder without TDZ.
>
> It isn't eval doing anything magic here - you can syntactically identify and use of not yet live properties, except eval(), e.g.
>
> function f1(a=b, b=...) ... // can syntax error easily
> function f2(a=function () {return b}, b=...) ... // again you can syntax error, or you can be clever and say we're not calling it and not error
> function f3(a=function () {return b}(), b=...) ... // syntax error as we can prove you're going to use b
> function f4(a=eval("b"), b=...) ... // eval makes things opaque
>
> Personally I don't believe TDZ's are a good solution - they essentially add another null/undefined value internally.  They make things more complex for developers.
>
> I certainly don't get what the TDZ win is for default parameters, and example would help me reason about it.

OK, I assumed you were talking about TDZ in general, and not just for
the specific case of parameter lists. For parameter lists, I agree
that there is no reason to treat them as mutually recursive. However,
if scoping of bindings is supposed to be sequential, but each default
expression shall see the previous parameters, then the only clean
solution is to conceptually have each parameter open a new nested
scope (like is the case in some other languages).  That solves your
'eval' case as well.  I'd be happy with that, but I remember concerns
about more fine-grained scoping on the committee.

As for TDZ in general, it is expressly _not_ the case that it
introduces another kind of nullish value -- because there is no value.
 Quite the contrary: its purpose is to avoid accidentally leaking
nullish error values into arbitrary computations, like it is plaguing
JavaScript elsewhere.  Instead, a recursive initialisation error
manifests immediately.

Also note again that there is no sane alternative for 'const' and
other immutable bindings, nor for a potential 'let' with guards. And
inconsistency is the worst possible choice.

/Andreas


More information about the es-discuss mailing list