Kevin Smith wrote:
>
>
>             x => { "use strict"; with (x) {} } // Not a strict-mode error
>
>
>     Spec bug if so -- that should make the arrow function so stated
>     have strict code.
>
>
> That would probably be the expectation, and I'm possibly just missing 
> something in the spec.  It does add an extra degree of complexity, 
> though.  Consider this edge case:
>
>     (x = function z(x) { delete x }) => { "use strict" }
>
> When we parse the invalid unary expression in function 'z', we don't 
> even know that we're in a "maybe strict" context yet.  It's only after 
> we see the "=>" that we know.

This is no different from

function f(x = function(y) { delete y }) { "use strict"; }

it seems to me. Really it's yet another parameter defaults vs. strict 
mode. The primal sin is the directive prologue coming in the body 
instead of before the parameter list, but that's ES5 strict, and 
arguably it's better to have a useless expression statement there (no 
new syntax was the rule), than new syntax or a magic comment or string 
literal expression statement "decorator" before the function.

> It's still doable without an AST walk though, I think.

Or a token stream rewind, as Jason pointed out.

/be

This is no different from

```js
function f(x = function(y) { delete y }) { "use strict"; }
```

it seems to me. Really it's yet another parameter defaults vs. strict 
mode. The primal sin is the directive prologue coming in the body 
instead of before the parameter list, but that's ES5 strict, and 
arguably it's better to have a useless expression statement there (no 
new syntax was the rule), than new syntax or a magic comment or string 
literal expression statement "decorator" before the function.

> It's still doable without an AST walk though, I think.

Or a token stream rewind, as Jason pointed out.