Allen Wirfs-Brock wrote:
On Apr 23, 2012, at 8:19 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
To be honest, that suggestion confirms one of my fears about "1JS" --
ending up with a more complicated language with ad-hoc rules about
which mode applies in which context. Please let's try to resist the
temptation. As much as I would like to encourage strict mode, I think
we should keep it orthogonal to other constructs as much as possible.
I can bear tying it to modules, but let's not go any further.
It's a good point (and I'm not one to "encourage strict mode" if there's no
payoff for developers, but before agreeing, can you enumerate the cases that matter
inside an arrow function body?
Without arguments runtime semantic shifts, and with |this| lexical, there
aren't many strict mode changes left IIRC, and they are pretty edgy edge cases.
See Annex C. Some strict mode highlights:
Assignment to an unbound name throws instead of creating a property of the
global object
Right. This one I want in new forms, and it's not ad-hoc if arrows imply
strict mode. Limiting strict mode implication to modules is just as
arbitrary and more user-hostile in my view. No one writing arrows wants
to create globals implicitly, only to save themselves by typing a "use
strict"; pseudo-pragma!
With statements are disallowed
Ditto^2.
direct eval can't instantiate new binding in the enclosing environment
Ditto^3.
duplicate formal parameter names are disallowed
We disallow duplicates if destructuring formal parameters appear in any
parameter list, in SpiderMonkey. We discussed doing this for any
function with destructuring parameters as part of the 1JS thread early
this year. I forget whether you spec'ed it already.
In that earlier discussion we did not agree that using a destructuring
formal parameter in a 'function' declaration or expression opts the body
of the function into strict mode. More the reverse -- one formal
parameter novelty does not say "strict throughout". But it can certainly
say "no duplicate formals" and no one minds. Duplicate formals are a
botch from ES1, added only to match JScript, IIRC.
(I suggest we add this restriction to arrow functions even if we say
they aren't inherently strict. )
Agreed.
1JS is about new syntax as opt-in for new semantics. Those new semantics can be strict in
some or all respects. There is nothing more ad-hoc about this than requiring "use
strict"; to opt-in, no one wants the botches you enumerate, and the implementations
already have strict mode factored mostly to compile time and can impute strictness to
arrows.
Really, the botches you enumerate *are* botches. They should not be perpetuated
into new function or module syntax where the body is introduced by a keyword
that can imply strictness. Neither users nor implementors want this. The
philosphical purity of separating concerns is an abstraction that is hostile to
the best interests of users from all testimony I've heard [*].
/be
[*] I've never heard from anyone defending any of the botches listed above
except for 'with', and when I push, it turns out people are using 'with' to
make PHP-style templates -- but the requirement for dynamic scope is a phantom
and one can generate even more efficient templates using Function or eval (and
libraries do).
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
