Intent to Ship: Explicit resource management (async)

[Rezvan Mahdavi Hezaveh]

Contact emails

rez...@chromium.org, s...@chromium.org

Explainer

https://github.com/tc39/proposal-explicit-resource-management/blob/main/README.md

Specification

https://tc39.es/proposal-explicit-resource-management

Summary

This feature addresses a common pattern in software development regarding the lifetime and management of various resources (memory, I/O, etc.). This pattern generally includes the allocation of a resource and the ability to explicitly release critical resources.

Blink component

Blink>JavaScript>Language

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

No known interop or web compat risk.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1569081) This is a TC39 Stage 3 proposal.

WebKit: Positive (https://bugs.webkit.org/show_bug.cgi?id=248707) This is a TC39 Stage 3 proposal.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This is a stage3 TC39 proposal.

Debuggability

We have added Devtools support for this proposal.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://github.com/tc39/test262/tree/05c45a4c430ab6fee3e0c7f0d47d8a30d8876a6d/test/staging/explicit-resource-management

Flag name on about://flags

None

Finch feature name

V8Flag_js_explicit_resource_management

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/42203814

Estimated milestones

Shipping on desktop	133
DevTrial on desktop	131

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5087324181102592?gate=5197892393107456

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACJ3t%2Bj1fJg-1ZzHPBkmDMrH1S%2BkCU0vA0ByLA-eMbDQ1K3qkg%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5175dbfa-d172-48bd-a8ab-596eb671d80f%40chromium.org.

[Rick Byers]

LGTM3

Love seeing more of the best parts of C# make it into ECMAScript :-)

Rick

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-FL7fRCeVNYu8-tKsXZKBduJiZogH8kyMTqRzYOH9xeA%40mail.gmail.com.

[Joshua Bell]

I'm excited to see this!

Is there any documented guidance for other web specs that want to integrate with this? If your spec already defines a release() or destroy() etc it can grow [Symbol.dispose]() (etc) as an alias. But do we want to encourage specs to settle on dispose() as the non-symbol name for consistency across the platform? And encourage specs to maintain a non-symbol method?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-pLcNJWn4c5Ncp-ioHHZ9u9bFQWpD6pF%2Bw68OfD%3DsUyw%40mail.gmail.com.

[Rezvan Mahdavi Hezaveh]

Joshua,

There is no guidance for other web specs as far as I know. But the disposable resources should have [Symbol.dispose]() or [Symbol.asynDispose](). For the non-symbol name, it is unlikely that TC39 answers this question because TC39 doesn't specify resources. Also, here is a research that the proposal champion has done on the relation of this proposal to DOM APIs that might be interesting to you https://github.com/tc39/proposal-explicit-resource-management?tab=readme-ov-file#relation-to-dom-apis

Bests,

Rezvan

[Joshua Bell]

Awesome, thank you! That research link is very useful.

While TC39 isn't on the hook for guidance on web specs, I'll tag in our local TAG rep +Jeffrey Yasskin as an FYI.

[Jeffrey Yasskin]

Thanks for the heads-up. I've proposed adding guidance to the design principles: https://github.com/w3ctag/design-principles/issues/537.