Skip to content

Editorial: non-syntactic async/generator functions use ReturnCompletion #3605

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

bakkot
Copy link
Contributor

@bakkot bakkot commented May 15, 2025

This moves the machinery for handling implicit returns in syntactic async/generator functions into the branches for evaluating parse nodes, instead of also using that logic for evaluating Abstract Closures.

It assumes that non-syntactic async/generator functions always internally return ThrowCompletions or ReturnCompletions. Right now they can use both ReturnCompletions or NormalCompletions, which provides an unnecessary degree of freedom. The alternative is to enforce that non-syntactic async/generator functions return ThrowCompletions or NormalCompletions, for which see #3606.

This makes non-syntactic async/generator functions unlike non-syntactic ordinary functions, which never use ReturnCompletion (and the machinery isn't set up to handle them). For that reason, I prefer #3606 over this PR.

You'll note a certain awkwardness in AsyncGeneratorStart: later in the algorithm ReturnCompletions are translated to NormalCompletions, for use as an argument to AsyncGeneratorCompleteStep. This accomplishes the same thing as the current If _result_ is a normal completion, set _result_ to NormalCompletion(*undefined*), but in a more roundabout way, and is necessary to avoid refactoring AsyncGeneratorCompleteStep.

(This PR would also require changing the existing built-in generators/async functions to never return NormalCompletions. I'll push up a commit doing that if we go this route.)

@bakkot
Copy link
Contributor Author

bakkot commented May 21, 2025

Editors are in favor of #3606, so closing this.

@bakkot bakkot closed this May 21, 2025
@bakkot bakkot removed the editor call to be discussed in the next editor call label May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant