block scope + direct non-strict eval

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Feb 1 08:21:03 PST 2012


On Feb 1, 2012, at 7:08 AM, Claus Reinke wrote:

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

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

The above code works the same in ES5 and ES6.  If it is strict code it returns 1.  If it is non-strict code it returns 2

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

> 
> 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? 

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120201/7393e197/attachment.html>


More information about the es-discuss mailing list