On Nov 26, 2013, at 5:21 PM, Brendan Eich wrote:

> Jason Orendorff wrote:
>> As long as
>> it's impossible to have code that parses in both modes, with different
>> meanings, it's not so bad.
> 
> Then we could have trouble, but perhaps do not:
> 
> function f(a = arguments[0] = 42) {
>  "use strict";
>  ...
> }
> 
> The "use strict" defeats arguments aliasing at runtime. Of course nothing differs in static semantics here, so this is actually easier to deal with than recasting lambdas in defaults as strict functions, e.g. The arguments object's semantic differences are entirely runtime semantic diffs.
> 
> Still, it's bothersome. We need to enforce the subset relationships you've identified: ES5 strict < ES6, and no static semantic deviations down the road. Summoning Mark along with Allen.
> 

In this case there are no static semantic differences between strict and sloppy mode. The difference is in the runtime semantics associated with s [[Set]] on the arguments object. 

In spec-land, this distinction is made during the FunctionDeclarationInstantiation runtime operation and manifest as what kind of object is create as the value of arguments.  Certainly runtime evaluation takes place after it was statically determined that f was  strict. If the generated code is going to differ between strict and sloppy mode then code generation also needs to be delayed until after that determination. 

Allen

On Nov 26, 2013, at 5:21 PM, Brendan Eich wrote:

> Still, it's bothersome. We need to enforce the subset relationships you've identified: ES5 strict < ES6, and no static semantic deviations down the road. Summoning Mark along with Allen.

In this case there are no static semantic differences between strict and sloppy mode. The difference is in the runtime semantics associated with s [[Set]] on the arguments object. 

In spec-land, this distinction is made during the FunctionDeclarationInstantiation runtime operation and manifest as what kind of object is create as the value of arguments.  Certainly runtime evaluation takes place after it was statically determined that f was  strict. If the generated code is going to differ between strict and sloppy mode then code generation also needs to be delayed until after that determination.