On 3 December 2014 at 23:09, 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();
>
> 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?

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).

/Andreas

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).