Allen Wirfs-Brock wrote:
To further clarify, consider this valid ES5 code that must continue to produce
the same result in ES6 :
function f(condition,body1,body2) {
if (condition) {
var code = "function f() {+body1+"}";
eval(code);
} else {
var code = "function f() {+body2+"}";
eval(code);
}
f();
}
We are talking about taking the variant of this code that removes the
eval calls by declaring functions in blocks, and breaking it. True, the
two are different cases. But the reason we hope we can break
function f(condition,val1,val2) {
if (condition) {
function f() { return val1; }
} else {
function f() { return val2; }
}
f();
}
is because it does not have interoperable semantics across major
browsers. When we banned function-in-block in ES5 strict, we did find
code that had "use strict"; prematurely applied before ES5-strict
implementations were available for testing, or applied via concatenation
of scripts. All such function in block cases were sane:
function f(condition,val1,val2) {
if (condition) {
function f() { return val1; }
val2 = f();
}
return val2;
}
or similar. The function-in-block not only dominates all its uses, all
uses are contained by the block in which the function is declared.
If eval was scoped exactly like a block, then this would fail because each
function declarations would be block scoped to a new block scope that was
inaccessible at the actual call site. To get the necessary compatible behavior
we have to hoist the function out of the block scope created for the eval all
the way up to the body scope (the Variable Environment) of the function, just
like var.
You're right, and this is what the SpiderMonkey function-in-substatement
provided (limited conditional compilation without eval). Crazy as people
say, and we want to remove it. Is it unthinkable to break compatibility
for the eval expansion?
This is will be an additional, scoping variation for function declarations
that only comes into play for non-strict evals.
If we have to keep compatibility, then we have 'function' requiring a
special case compared to 'let' with your option 2. Or we take option 1
and have all the forms, new (let and const) and old (var and function)
pollute non-strict direct eval's dynamic scope. Gah.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
