Hi
Section 13.4 of the new draft specifies two early errors that are needlessly restrictive:
* It is a Syntax Error if FunctionBody Contains YieldExpression is false.
"function* () {}" is well-defined, and might come about through use of eval code.
* It is a Syntax Error if AssignmentExpression Contains YieldExpression.
"yield yield 3" is also perfectly well-defined.
In both of these cases, an implementation would have to do more work to implement the restrictions than it would to not implement them.
This bug is still present in revision 15.
Do you have a real use case for a generator function body without a yield other than a by-product of a degenerate case of mechanical code generation?
If not, it's a trade-off between early diagnostics for human written code and a slight simplification of a code generator.
One important use case is prototyping with a dummy generator. Or the case where you comment out a yield for debugging. That shouldn't render the program illegal.
A zero iterator/generator could also be a perfectly sensible part of a generic iterator library. There is no reason to believe that you don't occasionally need an empty generator in the same manner you sometimes need empty functions.
Also, I don't think it simplifies code generators. If anything, it's more work to diagnose this case.
The fixed issue looks to be handled already in bug 1551.
In the interest of not filing duplicate bugs, I'll just add my +1 to
the remaining issue:
* It is a Syntax Error if AssignmentExpression Contains YieldExpression.
I don't really know what else to add aside from what Andy Wingo has
already said. At the very least, it would be useful to be able to know
what the rationale behind this limitation is.
Okay, maybe I will add something.
----
On the implementation side:
Once you have the capability to do something like:
function* G() {
f(yield a(), (yield b) + (yield c), 42 + yield d);
return yield e;
}
then you have almost certainly already implemented
function* G() {
yield f(yield a(), (yield b) + (yield c), 42 + yield d);
yield yield e;
}
Going back and disabling that particular case is almost certainly
going to be more work.
----
On the language-design side, having this limitation means that
programmers have to remember one more special-case rule. Normally you
would expect expressions to be freely nestable (modulo the use of
parens to handle precedence and parsing issues). If there are to be
exceptions, there should a clear reason for them.
So at the very least, there should be some rationale for this
exception in the spec.
Note that some people may prefer to have their lint tools disallow
nested yield expressions, but this should probably be a separate issue
from what is allowed in the language itself.
----
P.S. I have no experience with the conventions of bugzilla, much less
ecmascript.org's particular usage of bugzilla. Does the "CONFIRMED"
bug status mean that this is going to be fixed in the next revision of
the spec? If so, sorry for the extra noise.
fixed (both items) in rev 16 editor's draft
fixed in rev16 draft. July 15, 2013