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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131110/f3f5d115/attachment.html>

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:

```js
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?

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:

```js
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?