I didn't think it was worth adding an assert in FunctionDeclarationInstantiation which says that IteratorBindingInitialization cannot produce a return completion in this specific case, but I'm open to doing so if we can do it without making the algorithm too awkward.

I think an assert would be helpful here because it would explain why return completions can't be returned (the guaranteed absence of yield).

Suggest a wording? The main trouble is that we're using Perform ? ... and I don't want to switch that to a Let _completion_ be Completion(...) just so we can write the assert. I guess we could do "The previous step cannot return a ReturnCompletion" or something but that's kind of awkward. Also there's two calls, which would each need such an assert.

The invocations of IteratorBindingInitialization only differ in the second parameter, so you can deduplicate them by creating an alias for that parameter. Then, yeah, "the following step cannot return a ReturnCompletion because ..." (I prefer notes before a step to notes after a step).

Also, an xref to the early error (sec-generator-function-definitions-static-semantics-early-errors) would be great.

Done:

1. Assert: The following step cannot return a ReturnCompletion because the only way such a completion can arise in expression position is by use of |YieldExpression|, which is forbidden in parameter lists by Early Error rules in <emu-xref href="#sec-generator-function-definitions-static-semantics-early-errors"></emu-xref> and <emu-xref href="#sec-async-generator-function-definitions-static-semantics-early-errors"></emu-xref>.

In EvalDeclarationInstantiation we have very similar steps, but as Note rather than Assert:

NOTE: The following invocation cannot return an abrupt completion because of the validation preceding step 14.

I guess either's technically fine, but Note is probably more appropriate since it's prose-y rather than a present-tense statement about some value. Switched it over.