block scope + direct non-strict eval

[Claus Reinke]

>> Btw, how does versioning work across eval? If I have a function body with 
>> an eval in it, will the body/eval run as in ES5 or as in ES6? Will that 
>> change if the body or the eval contain ES6 features? Will ES5/ES6 scripts 
>> be able to eval ES6/ES5 code?
>>
> On this very thread we are hashing out how eval("let x = ...") interacts 
> with the dynamic scope.

Yes. Prompted by this, I am trying to understand how eval interacts with
implicit versioning ("no ES6 opt-in"; btw, is the current state of 
discussion
on opt-in summarized somewhere? I get lost in the threads here, and the
wiki seems to predate this discussion).

Both ES6 detection-by-feature-use and some ES6 features imply static
checks, with a clear phase distinction between a static and a dynamic phase.
eval ensures that ES is multi-staged (static/dynamic phase switches may
occur nested, with the static phase of an eval occurring during the dynamic
phase of the outer code that reaches that eval).

> ..[ points about direct vs indirect eval, strict vs non-strict code]..

These precedents seem to suggest that the eval code language version
will mostly be independent of versioning the outer code. Which seems
sensible: the eval source is dynamic data, so cannot be used for static
language version determination of outer code; and, on a larger scale,
we want to be able to eval both ES5 and ES6 code. But, on a smaller
scale, that means that eval can be used to embed ES5 features in ES6
code, and vice versa.

Take this problematic example from the old no-opt-in thread:

> function f(a) {
>     arguments[0]=2;
>     return a
> }
> print(f(1));  //2 if ES5, 1 if ES6
>
> There is nothing in the source file that implies which specification to 
> apply so for backwards computability a browser must default to 
> interpreting such program as a ES5 program. Anything syntactically
> unique to ES5 (eg, use of a with statment) or ES6 (eg, use rest or spread) 
> would force one interpretation or another

and embed the assignment in an eval:

> function f(a) {
>     eval("arguments[0]=2");
>     return a
> }
> print(f(1));  // 2 or 1?

If the language version for eval code is independent of the context,
we could have ES5 features used in the middle of ES6 code (so the
result could be 2 even if f is part of ES6 code, unless such cross-version
interactions are prevented by a dynamic barrier), and vice versa. If the
language version for the eval code is not independent of the context,
we have other problems.

Claus