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

> See https://bugs.ecmascript.org/show_bug.cgi?id=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..."`.

Dmitry


>
> 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?
>
> Allen
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141203/7f41ff46/attachment-0001.html>

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

> See https://bugs.ecmascript.org/show_bug.cgi?id=3383
>
> The issue concerns things like this:
>
> ```js
> "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..."`.