Scoping of non-strict direct evals in parameter expressions

# Allen Wirfs-Brock (10 years ago)

See ecmascript#3383

The issue concerns things like this:

"don't use strict";
var x="outer"
function f(a=eval(" var x=1;  42"),
                 x=eval(" console.log("can"+(x!=1?"'t":"")+" see earlier eval binding"}; 84")
                 ) {
     console.log(x); // ? "outer" , 1, or  84?
}
f();

In other words, for non-strict functions, in what scope does should a direct eval that occurs in a parameter list expression context create its declarations. Remember that formal parameters have their own scope contour that is separate from the body scope (and the environment for the body scope doesn't even exist during parameter expression evaluation. Also remember that legacy non-strict direct evals within functions create vars (and functions) in the variable scope of the function (which is the same as the body scope).

I propose, that for scoping purposes, we treat such evals (parameter expression + non-strict + direct) as if they were strict evals. That means that all declarations created by the eval code are created in a new environment record that is discarded when the eval completes. Basically, it means that evals in parameter expression can't create bindings that are visible outside of the eval.

Also, note that I'm not proposing that strict mode rules such as banning 'with' be applied to the body of the eval. I'm just talking about the declaration scoping rules. This introduces a sort of "micro-mode" but the alternatives see less desirable. They are 1) figure out a semantics of declarations injected into the function from parameter list evals; 2) force parameter list direct evals into full trict mode. The first is hard, complex, and probably pointless; the second is still a sort of micro-mode, seems less aligned with the likely user intent, and I think will actually be harder to specify.

Thoughts?

# Dmitry Soshnikov (10 years ago)

On Wed, Dec 3, 2014 at 2:09 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

See ecmascript#3383

The issue concerns things like this:

"don't use strict";
var x="outer"
function f(a=eval(" var x=1;  42"),
                 x=eval(" console.log("can"+(x!=1?"'t":"")+" see earlier
eval binding"}; 84")
                 ) {
     console.log(x); // ? "outer" , 1, or  84?
}
f();

As it's now, it should be 84 seems, but with creation of x with the value 1, then printing "can see earlier eval binding".

In other words, for non-strict functions, in what scope does should a direct eval that occurs in a parameter list expression context create its declarations. Remember that formal parameters have their own scope contour that is separate from the body scope (and the environment for the body scope doesn't even exist during parameter expression evaluation. Also remember that legacy non-strict direct evals within functions create vars (and functions) in the variable scope of the function (which is the same as the body scope).

I propose, that for scoping purposes, we treat such evals (parameter expression + non-strict + direct) as if they were strict evals. That means that all declarations created by the eval code are created in a new environment record that is discarded when the eval completes. Basically, it means that evals in parameter expression can't create bindings that are visible outside of the eval.

Yeah, since defaults params and the the whole intermediate params scope is the whole new semantics, we can easily make this strict eval evaluation in its isolated environment. Seems the easiest solution, so eventually the x will be "outer", and "can't see...".

# Andreas Rossberg (10 years ago)

On 3 December 2014 at 23:09, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

Thoughts?

Sounds good to me. FWIW, I wouldn't consider this a micro-mode. It's just scoping: every default expression simply executes in a new (declaration) scope. You don't even need to change the rules for eval itself, it can be specified completely independent of what the expression is. If you model it that way, then it automatically extends to future do-expression as well (which might also be abused to create 'var's in default expressions).