1js, local fundecls, and not-quite-conforming pre-es6 implementations
Claus Reinke wrote:
But with 1JS, I'm no longer sure what happens when new code that relies on local FunDecls (and no other ES6 features) encounters an old implementation. It looks as if there will be no warning or error, just irreconcilable differences in behaviour?
That's the case already, with old code using function declarations in blocks.
Such code typically has the form
/* A / if (B) { / C / function D(...) {...} / E / } / F */
where only code in /* E / uses D. Anything else relies on hoisting (not done by SpiderMonkey in Firefox) or unconditional binding (in / F */, not done by SpiderMonkey).
So (we hope) the problem is not actually present in portable code. We've seen real code like this. See bugzilla.mozilla.org/show_bug.cgi?id=630851#c8 for details.
Is the recommendation that local FunDecls should only be used in combination with explicit ES6 syntax (to trigger opt-in or explicit errors)?
No, that's too restrictive.
Should this recommendation appear in the spec (the old Note was deleted)?
Probably not, but some kind of NOTE might be appropriate.
What was the story wrt subject?
The Note in ES5.1, 12, Semantics (FunctionDeclarations as Statements) used to be unproblematic as this non-portable feature could simply be avoided.
It also was unproblematic when ES.next still required opt-in, as old implementations would then balk before reaching local FunDecls.
But with 1JS, I'm no longer sure what happens when new code that relies on local FunDecls (and no other ES6 features) encounters an old implementation. It looks as if there will be no warning or error, just irreconcilable differences in behaviour?
Is the recommendation that local FunDecls should only be used in combination with explicit ES6 syntax (to trigger opt-in or explicit errors)? Should this recommendation appear in the spec (the old Note was deleted)?
Claus clausreinke.github.com