The JavaScript explicit resource management proposal by Microsoft's @rbuckton, at Stage 3 in TC39, defines a new protocol with a method called [Symbol.dispose] for resource cleanup. There is a nice syntax using resource = expr; which calls resource[Symbol.dispose]() at the end of the lexical scope--analogous to C++ RAII, Go defer, Python with, etc.
I'm filing this issue not to ask for a TAG review of that proposal (this could be done separately) but to start the discussion about how Web Platform APIs should use this new protocol. Many of the motivating use cases are for server environments, but many web APIs may also tie into this protocol--one idea described here.
Another place we're discussing this topic is https://github.com/whatwg/html/issues/8557 . Note the question raised there about how cancellation and disposal should relate. In some mechanical sense, the APIs are dual of each other--for each void-returning API that takes an AbortSignal as a parameter, it would be equivalently expressive for that API to return an object representing the ongoing operation which could instead be disposed to unsubscribe/cancel. However, in many other programming environments, the semantics of cancellation and disposal are very different; for that reason, the integration proposed in the JS proposal readme does not mention cancellation.
It would be ideal if the TAG design principles contained clear guidelines to be used across the web platform to explain the appropriate way to design APIs using Symbol.dispose and/or AbortSignal.
Wotcher TAG!
The JavaScript explicit resource management proposal by Microsoft's @rbuckton, at Stage 3 in TC39, defines a new protocol with a method called
[Symbol.dispose]for resource cleanup. There is a nice syntaxusing resource = expr;which callsresource[Symbol.dispose]()at the end of the lexical scope--analogous to C++ RAII, Godefer, Pythonwith, etc.I'm filing this issue not to ask for a TAG review of that proposal (this could be done separately) but to start the discussion about how Web Platform APIs should use this new protocol. Many of the motivating use cases are for server environments, but many web APIs may also tie into this protocol--one idea described here.
Another place we're discussing this topic is https://github.com/whatwg/html/issues/8557 . Note the question raised there about how cancellation and disposal should relate. In some mechanical sense, the APIs are dual of each other--for each void-returning API that takes an AbortSignal as a parameter, it would be equivalently expressive for that API to return an object representing the ongoing operation which could instead be disposed to unsubscribe/cancel. However, in many other programming environments, the semantics of cancellation and disposal are very different; for that reason, the integration proposed in the JS proposal readme does not mention cancellation.
It would be ideal if the TAG design principles contained clear guidelines to be used across the web platform to explain the appropriate way to design APIs using Symbol.dispose and/or AbortSignal.