Editorial: return ~unused~ from closures passed to GeneratorStart

[michaelficarra]

GeneratorStart step 4.i.i ignores the value returned by the AC, so return ~unused~ instead of *undefined* to be less confusing.

[bakkot]

I would prefer to go the other direction, as in tc39/ecma262#2924, and ensure that the abstract closures passed to GeneratorStart can only ever return return completions or throw completions.

[michaelficarra]

You want these to all be ReturnCompletion(*undefined*)?

[bakkot]

I want GeneratorStart to assert that _result_ is either a return or throw completion (like how tc39/ecma262#2924 now does for the result of OrdinaryCallEvaluateBody). That could be done either by having these return ReturnCompletion(*undefined*), or by having the abstract closure branch in GeneratorStart step 4.d rewrite normal completions to return completions, in which case these closures would continue to return *undefined* (but not ~unused~).

I think it's more natural this way: the only reason normal completions arise when evaluating syntactic generators is the implicit return from running off the end of a function body, which is why their [[Value]] is ignored and replaced with *undefined*, and I think it's best to handle that complexity closer to its source (i.e., in EvaluateFunctionBody) rather than having the more general machinery in GeneratorStart need to deal with it.

[michaelficarra]

Yes but these are synthetic generators we're talking about here, not syntactic generators, and I'd prefer the AC to not have to provide a meaningful return value when they want to cease yielding values.

[bakkot]

I think that GeneratorStart should not have any logic which is specific to dealing with the oddities of syntactic implicit returns, which it currently does (that's what the normal completion case is).

And there is necessarily some value which goes in the .value of the first iterator result object after the last yielded value. I think it's better to be explicit in the closures that this value is *undefined*, rather than relying on machinery which is only there to handle syntactic implicit returns.

[bakkot]

If you want to say that no built-in generators can ever have non-undefined return values, we could make the abstract closure branch in GeneratorStart 4.d explicitly set _result_ to ReturnCompletion(*undefined*) when _result_ is a normal completion, I guess? But I don't see any reason to build that limitation into the machinery.

[michaelficarra]

If you want to say that no built-in generators can ever have non-undefined return values

Yes, I think that is fine to say. It is going to be *undefined* in literally every use. I'd rather use ~unused~ to tell the reader "nothing special here" than have to figure out where this *undefined* value is going.