On Dec 27, 2012, at 1:23 AM, Andreas Rossberg <[email protected]> wrote:
>> 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:
>
> I think nobody ever proposed going for this semantics, so we can put that
> aside quickly. However:
OK, well, it wasn't clear to me.
>> var x;
>> if (...) { x = ... }
>> if (x === undefined) { ... }
>>
>> If you want to use let instead, the === if-condition will throw. You would
>> instead have to write:
>>
>> let x = undefined;
>> if (...) { x = ... }
>> if (x === undefined) { ... }
>
> That is not actually true, because AFAICT, "let x" was always understood to
> be equivalent to "let x = undefined".
Well that's TDZ-UBI. It *is* true for TDZ-RBA. Maybe I was the only person who
thought that was a plausible semantics being considered, but my claim (P => Q)
is true. Your argument is ~P. Anyway, one way or another hopefully everyone
agrees that TDZ-RBA is a non-starter.
>> 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.
>
> 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.
OK, I'll accept that Crock's manual-hoisting style only matters for `var`. I
just want to be confident that there are no other existing benefits that people
get from the equivalence (either in programming patterns or
refactoring/transformation patterns) that will break.
> 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?
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
