Brendan Eich (2013-11-26T00:48:03.000Z)
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
domenic at domenicdenicola.com (2013-12-10T01:14:01.321Z)
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!