Python has requirements for over-parenthesization which we were trying 
to avoid. Nevertheless, did you consider

5. Except on right of assignment and in actual argument position, yield 
expressions must be parenthesized

This is easy to do grammatically if we change the over-general

ClassHeritage :
|    extends| AssignmentExpression

I say over-general because: do we really want this to be valid ES6?

class D extends B = C {
}

Using a higher-precedence expression non-terminal seems better. How 
about the next lower-precedence nonterminal that does not end in 
AssignmentExpression, namely LogicalORExpression?

Then any yield without parentheses would be a syntax error.

/be
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> November 10, 2013 6:46 PM
> see bug: https://bugs.ecmascript.org/show_bug.cgi?id=2011
>
> The decision to make the AssignmentExpression optional within a 
> YieldExpression creates an ambiguity when combined with class 
> declarations. For example cosider:
>
> function *gen() {
>         class Foo extends yield {}
>            { }
> }
>
> Is the intent for a yield expression that yields a new object or a a 
> yield expression with yields a implicit undefined.  Neither a human 
> nor a parser can know for use what the authors actual intent was.
>
> There are several ways we could fix this problem:
>
> 1) Retract the decision to make the yield assignment expression 
> optional.  In this case a 'yield', in all yield expression contexts, 
> would have to always be followed by an explicit expression producing 
> the value to yield.
>
> 2) Make the use of 'yield' illegal in the 'extends' clause of class 
> declarations. Arguably this is comparable to the restrictions on the 
> use of 'in' within for-in statements.  This would probably not be a 
> major usage issue as actual use cases of 'yield' in that context seems 
> quite implausible.
>
> 3) Continue to allow usage of 'yield' expressions in 'extends' clauses 
> but make the AssignmentExpression part of the YieldExpression 
> mandatory in that context.
>
> 4) some other, even more ad hoc, disambiguation rule.
>
> Either #1 or #2 would be trivial to specify. #2 would be a straight 
> forward use of an expression grammar parameter that we already have.
>
> #3 is somewhat harder to specify and requires a new parameter on all 
> of the expression grammar productions.  It would require more 
> editorial work to implement and result in a more cluttered grammar 
> definitions.
>
> #4 needs an actual proposal that can be evaluated.
>
> I would be happy with either alternative #1 or #2.
>
> The actual utility of a YieldExpression in an 'extends' clause seems 
> so low that I don't think we should make the entire expression grammar 
> more complicated just to support alternative #3.
>
> Thoughts?
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Python has requirements for over-parenthesization which we were trying 
to avoid. Nevertheless, did you consider

5\. Except on right of assignment and in actual argument position, yield 
expressions must be parenthesized

This is easy to do grammatically if we change the over-general

```
ClassHeritage :
|    extends| AssignmentExpression
```

I say over-general because: do we really want this to be valid ES6?

```js
class D extends B = C {
}
```

Using a higher-precedence expression non-terminal seems better. How 
about the next lower-precedence nonterminal that does not end in 
AssignmentExpression, namely LogicalORExpression?

Then any yield without parentheses would be a syntax error.