Skip to content
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.

Sign up for GitHub

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

Jump to bottom

add async-explicit-resource-management #300

Merged
merged 2 commits into from
Mar 23, 2023
Merged

add async-explicit-resource-management #300

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2d128c3
add async-explicit-resource-management
JLHwung Feb 1, 2023
af01d7f
using "await using" as kind
JLHwung Mar 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 15 additions & 0 deletions experimental/async-explicit-resource-management.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# [Async Explicit Resource Management][proposal-async-explicit-resource-management]

# Declarations

## VariableDeclaration

```js
extend interface VariableDeclaration {
kind: "usingAwait";
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative design is

extend interface VariableDeclaration {
    await: boolean;
}

We have the same design in ForOfStatement. However, in this case, the other kinds, namely var, let and const do not have await counterparts. So I figure it would be more efficient to pack the await flag into the kind string.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like the correct course of action given that constraint.

Would we also have a kind: "using" for sync disposal?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we already have https://github.com/estree/estree/blob/master/stage3/explicit-resource-management.md

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! I think my only question then is, in the final version, do we want kind: "using await" instead of kind: "usingAwait" to match the actual syntax?

Copy link
Contributor Author

@JLHwung JLHwung Feb 8, 2023 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I slightly prefer usingAwait or asyncUsing if other syntax is adopted, because "camelCase" is slightly shorter than "camel case". I think we can trust TC39 that usingAwait variable will never be approved alongside the using await variable, so either kind: "using await" or kind: "usingAwait" should be good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm slightly more in favor of kind: "using await" to have it more closely match the actual syntax. I was also looking through the spec, and it seems like we don't have other instances of string values in camel case. Though, to be fair, we also don't have other instances of string values with spaces, so that's probably not a great argument. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think I’m more in favor of “using await” to match actual syntax. This is important for code generators that take in the AST and output source code. If we use “usingAwait”, every code generator will need to be updated to catch this special case. With “using await”, no changes will be necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong preference. Either "using await" or "usingAwait" is fine. I am waiting for resolution of the next meeting, since we may have to change that again if "async using", after that I will go with your approach.

Speaking of code generator, if they don't handle edge cases like using /* feeling lucky */ await foo = ..., they can proceed with printing node.kind as-is.

```

If `kind` is `"usingAwait"`, for every declarator `d` of `declarations`, `d.id` must be an Identifier. If the variable declaration is the `left` of a ForOfStatement, `d.init` must be `null`, otherwise `d.init` must be an Expression.

[proposal-async-explicit-resource-management]: https://github.com/tc39/proposal-async-explicit-resource-management