ES6 lexical temporal dead zone has landed on central

[Shu-yu Guo]

Hello all,

Today I landed bug 1001090 (assuming it doesn't bounce), implementing ES6
lexical temporal dead zone for function-level `let` declarations, on
mozilla-central. As a refresher on the email I sent on Aug. 13, this is a
backwards-incompatible change.

Everything inside mozilla-central needed to make the tree green on TBPL has
been fixed. However, this is expected to break addons, comm-central, and
possibly B2G code that use `let` (though I was told last time that Gaia does
not use `let`).

If you work with JS that contains `let` bindings, you may start encountering
the following two errors:

1. TypeError: redeclaration of variable foo

To fix, rename the variable or remove the extra `let` if you are
assigning to an already-bound variable.

These are static errors. You may pass your JS through the syntax checker
in the SpiderMonkey shell (-c) to detect them.

2. ReferenceError: can't access let declaration `foo' before initialization

These are hoisted uses and wacky cases like accessing a `let` binding
declared in one switch case in a different case. To fix, don't do those
things please.

These are dynamic errors. You have to execute your JS to detect them.

--
shu

[Philip Chee]

On 16/09/2014 07:43, Shu-yu Guo wrote:
> Hello all,

> Everything inside mozilla-central needed to make the tree green on TBPL has
> been fixed. However, this is expected to break addons, comm-central, and
> possibly B2G code that use `let` (though I was told last time that Gaia does
> not use `let`).

Hello!

In future please remember to file appropriate bugs in comm-central
*before* landing such tree-wide changes. Your cooperation is appreciated.

Yours sincerely,

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Mark Banner]

On 16/09/2014 09:09, Philip Chee wrote:
> On 16/09/2014 07:43, Shu-yu Guo wrote:
>> Hello all,
>
>> Everything inside mozilla-central needed to make the tree green on TBPL has
>> been fixed. However, this is expected to break addons, comm-central, and
>> possibly B2G code that use `let` (though I was told last time that Gaia does
>> not use `let`).
>
> Hello!
>
> In future please remember to file appropriate bugs in comm-central
> *before* landing such tree-wide changes. Your cooperation is appreciated.

Sorry, but I have to correct you. This is NOT a requirement on
gecko/Firefox developers.

If we can get notification (via cc, this list, other lists or via bugs)
of big, potentially-breaking changes, before they land, that is
appreciated and is useful to us as it helps save time. However, we
recognise this isn't always possible/practical (or remembered).

It is the responsibility of comm-central maintainers/developers to
ensure any necessary bug filing takes place. This doesn't stop
gecko/Firefox developers from filing bugs and helping us out, but it
certainly isn't a requirement.

Mark.

[Philipp Kewisch]

On 9/16/14 11:20 AM, Mark Banner wrote:
> If we can get notification (via cc, this list, other lists or via bugs)
> of big, potentially-breaking changes, before they land, that is
> appreciated and is useful to us as it helps save time. However, we
> recognise this isn't always possible/practical (or remembered).

I agree with Mark here, its nice to get bugs filed but its surely not a
requirement.

IIRC then this was also announced on the list a while back, so
everything that could have been done has been done.

Philipp

[Kent James]

See bug 1054357 that I filed for this issue on 2014-08-15 based on the
2014-08-13 m.d.platform post.

:rkent

[Philip Chee]

Ah, I was on holiday for most of August so I never saw that.

[Chris Peterson]

On 9/15/14 4:43 PM, Shu-yu Guo wrote:
> If you work with JS that contains `let` bindings, you may start encountering
> the following two errors:
>
> 1. TypeError: redeclaration of variable foo
>
> To fix, rename the variable or remove the extra `let` if you are
> assigning to an already-bound variable.
>
> These are static errors. You may pass your JS through the syntax checker
> in the SpiderMonkey shell (-c) to detect them.

Much of the `let` fallout being reported is from variable
redeclarations. For compatibility, perhaps TC39 should reconsider
whether `let` redeclarations are worthy of being static errors.

JS allows you to redeclare vars. Rust allows you to redeclare variables
with `let` (even changing the type!). SpiderMonkey's non-standard JS1.8
allowed you to redeclare variables with `let` (until Shu made it ES6
compatible). Maybe variable redeclarations are not such a big problem
for JS developers.

chris

[Shu-yu Guo]

Well, SM's 'let' extension never really let you redeclare let bindings. What happened was that it was too much work to parse function body-level lets as actual lets, and so they were parsed as vars, thus allowing "redeclarations".

Keep in mind that vars aren't *really* redeclared. When actual semantics is closer to erasure semantics: just pretend the second var isn't there. That is, consider

var x = 42;
var f = function () { print(x); }
var x = 43;
var g = function () { print(x); }

f and g above are closing over the *same* binding of x.

I would bet that Rust lets you actually redeclare (viz. shadow with a new binding in the same scope) , such that if you had the equivalent code in Rust above, f and g would close over *different* bindings.

So having lets behave like vars in that respect is probably going to lead to the same crappiness that we have with vars now. Why they didn't allow shadowing with a new binding? I don't know, it would be nice -- but perhaps was too big a break, and that it would behave strangely, or at least surprisingly, with hoisting semantics.

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Bill McCloskey]

If this change proves to be really disruptive to add-on authors, I wonder if we could just make "let" behave like "var" for add-ons? The JS tokenizer could just substitute var for let when parsing code from an add-on compartment. (Bug 1030420 will put add-on code in a separate compartment and it's ready to land soon.) I think that would mostly mitigate the concerns Jeff raised in the previous thread about having to test two configurations.

-Bill

[Philipp Kewisch]

Is the AMO compatibility checker powerful enough to detect at least the
first category of required changes? If so I don't think we should make
any more special cases than needed.

While the change is annoying for addon authors, in most cases the
redeclaration is just an oversight and it would improve style to fix it.

Philipp

[Bobby Holley]

It would probably be easy for them to fix, yes. But we have a roughly fixed
amount of capital with addon authors with which to force them to make
compatibility fixes - at some point, some number of them get fed up and
stop updating their code. I'm really not sure that this is a worthy place
to spend it.

+1 to Bill's idea.

[Jorge Villalobos]

Kris from the Add-ons Team is already looking into this and will message
developers affected by this issue.

Jorge

[Jonas Sicking]

On Thu, Sep 18, 2014 at 1:41 AM, Bobby Holley <bobby...@gmail.com> wrote:
> It would probably be easy for them to fix, yes. But we have a roughly fixed
> amount of capital with addon authors with which to force them to make
> compatibility fixes - at some point, some number of them get fed up and
> stop updating their code. I'm really not sure that this is a worthy place
> to spend it.
>
> +1 to Bill's idea.

Though I also think that developers will appreciate using "real" JS.
And presumably the current JS semantics were created for good reasons
and actually something that authors ultimately prefer.

So I don't think we should think of converting to standard semantics
here as purely a cost.

Ultimately I think we should check with addon authors before making a
decision one way or another.

/ Jonas

[Kent James]

On 9/17/2014 7:51 PM, Bill McCloskey wrote:
> If this change proves to be really disruptive to add-on authors, I wonder if we could just make "let" behave like "var" for add-ons? The JS tokenizer could just substitute var for let when parsing code from an add-on compartment. (Bug 1030420 will put add-on code in a separate compartment and it's ready to land soon.) I think that would mostly mitigate the concerns Jeff raised in the previous thread about having to test two configurations.
>
> -Bill

Substituting var for let does not result in code that behaves
identically to previous code, so I can't see why that would be proposed.

These two snippets give different results:

let s = "valid";
{ let s = "invalid";}
dump(s);

gives a different result than
var s = "valid";
{ var s = "invalid";}
dump(s);

If you wanted a reasonable compromise, only flagging the duplicated
definition of "let" in strict mode would be a viable solution.

:rkent

[Jeff Walden]

On 09/18/2014 04:18 PM, Kent James wrote:
> Substituting var for let does not result in code that behaves identically to previous code, so I can't see why that would be proposed.

The proposal would be to perform the substitution only for let at "body level" of a function. (And for global let -- which requires its own semantic changes, see bug 589199, that are in progress but not complete yet.) So this:

let s = "valid";
{ let s = "invalid";}
dump(s);

would be converted to this:

var s = "valid";

{ let s = "invalid";}
dump(s);

with no semantic change.

This substitution is absolutely not a good idea in the long run. In the short run, for a release or two...maybe. But that's a veeeery hesitant maybe. I'm leery of introducing these deviations into the language, such that people write code expecting the standard semantics and are surprised to find the code doesn't work as expected in other contexts. How should addons that inject code into pages behave, for that code? Is this something that an addon author could easily predict? I could well imagine it working either way. I'd really rather not go down this path if we can help it.

Jeff

[Shu-yu Guo]

I'm with Jeff on this one. I'm very much against special casing add-on code -- which will invariably develop into another compatibility to break when we finally do decide to break it.

----- Original Message -----
From: "Jeff Walden" <jwald...@mit.edu>
To: dev-pl...@lists.mozilla.org
Sent: Friday, September 19, 2014 5:51:38 PM
Subject: Re: ES6 lexical temporal dead zone has landed on central