On 11/25/2013 04:48 PM, Brendan Eich wrote:
> Brendan Eich wrote:
>> Kevin Smith wrote:
>>>     This makes for wtfjs additions, but they all seem non-wtf on
>>>     reflection (or did to us when Waldemar threw them up on a
>>>     whiteboard last week). By non-wtf, I mean anyone who groks that
>>>     yield is reserved only in function* can work them out.
>>>
>>>     The star after function really helps. ES5's "use strict" directive
>>>     prologue in the body applying to its left (even in ES5 --
>>>     duplicate formals are a strict error) is goofy.
>>>
>>>
>>> Agree on all counts, but not quite understanding yet.
>>>
>>> Say I'm parsing this, and the token stream is paused at the "#":
>>>
>>>     function(a = # yield
>>>
>>> I assume that we're not un-reserving yield in strict mode.  That means that I don't know whether to treat `yield` as an identifier or reserved word until I get to that goofy prologue.
>>
>> Ouch, you're right. We can't handle this without backtracking. Waldemar should weigh in.
>
> Well, we can handle it. We know due to lack of * after function that yield, whether reserved (due to "use strict"; in body prologue) or not, can't be yield-the-operator. So it's either an identifier (no "use strict";) or a reserved word (and an error due to lack of * after function).
>
> So we parse it as an identifier, just as we parse duplicate formal parameters. Then if we see "use strict", we must post-process the parse tree and throw an error. Kind of a shame, but there it is.
>
> At least reserving 'let' in ES5 strict did some good!
>
> /be

For another example of why keying off generator/non-generator instead of strict mode for the parsing of yield is the right thing to do:

function*(a = yield/b/g) {
   a = yield/b/g;
}

One of these is a regexp.  The other is a couple divisions.

Get this wrong and you can introduce security problems.

     Waldemar

On 11/25/2013 04:48 PM, Brendan Eich wrote:
> Well, we can handle it. We know due to lack of * after function that yield, whether reserved (due to "use strict"; in body prologue) or not, can't be yield-the-operator. So it's either an identifier (no "use strict";) or a reserved word (and an error due to lack of * after function).
>
> So we parse it as an identifier, just as we parse duplicate formal parameters. Then if we see "use strict", we must post-process the parse tree and throw an error. Kind of a shame, but there it is.
>
> At least reserving 'let' in ES5 strict did some good!

For another example of why keying off generator/non-generator instead of strict mode for the parsing of yield is the right thing to do:

```js
function*(a = yield/b/g) {
   a = yield/b/g;
}
```

One of these is a regexp.  The other is a couple divisions.

Get this wrong and you can introduce security problems.