block scope + direct non-strict eval

Claus Reinke claus.reinke at
Thu Feb 2 02:07:30 PST 2012

> No, things changed at the last TC39 meeting.
> New features can generally be used anywhere.  All code is
> non-strict unless it is either made strict using a use strict
> directive or contained within a module body (module bodes
> have an implicit "use strict").

Okay, that wasn't clear to me from the meeting notes. In general,
I've completely lost track of what ES6 is going to look like: too
many variations and re-designs in the mailing list threads, no way
for me to distinguish member preferences from committee
agreements. As the wiki no longer seems to represent the latest
agreements, I'll have to wait for your next spec update (and hope
that there isn't another thread that obsoletes the spec update).

>> and embed the assignment in an eval:
>>> function f(a) {
>>>    eval("arguments[0]=2");
>>>    return a
>>> }
>>> print(f(1));  // 2 or 1?
> same as above, same as ES5

But if I put this in a module, f will be in extended strict mode, while
the eval code will default to non-extended non-strict mode, right?
Which wouldn't quite be the same as in the version without eval.

>> 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.
> Sticking with the strict/non-strict distinction, can you give an example
> where a ES6 feature within a strict direct eval within a non-strict code
> context would be problematic?

I'm not yet sure whether any of this is problematic, I'm just trying to
pin down how the static determination of language mode is going to
work in the presence of eval, and what the interactions are.


More information about the es-discuss mailing list