How should web standards use the new JavaScript Symbol.dispose protocol?

[littledan]

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 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 whatwg/html#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.

[littledan]

Note, my goal here is to get something into the design principles document, and then follow up from there with proposals to change all relevant other specifications; this isn't a small, quick, self-contained question.

[domenic]

My current thinking is web platform specs should not do any work in this area until there is parity between async and sync dispose. Having only a random subset of web objects (those with sync disposal) be usable with this new syntax is something I'd like to avoid on the web platform. And having to push the spec/implementation/tests ecosystem through an adoption curve twice, once for sync and once for async, is not something I think the community should spend time on. (Certainly it's something I'll advise Chromium spec and implementation engineers against spending time on.)

[bakkot]

Fortunately it looks likely async dispose will be reaching stage 3 at the end of this month, with parity (including syntax) with sync dispose. So I think it's worth thinking about what your answer would be in a world in which sync and async dispose both exist with similar affordances.

[littledan]

I can definitely understand not adopting this as a standard yet, but I'm wondering, do your thoughts on how the web platform should integrate with disposal align with the notes that @rbuckton has published?

[littledan]

Namely, these notes:

• https://github.com/tc39/proposal-explicit-resource-management/#relation-to-dom-apis
• https://github.com/tc39/proposal-async-explicit-resource-management/#relation-to-dom-apis

[domenic]

That's great news!!

I think I'm generally aligned with many of those recommendations, although some are more obviously good than others. Eyeballing it I'd suspect 50-70% of the suggestions there seem uncontroversial and the rest might need more discussion and confirmation.

Generally it's most obvious that the dispose protocol is a good fit if the object is "short lived" in a spatial sense (e.g. a reader/writer). It's less obvious but still probably a good fit if it has a lifecycle that is often tied to some other object (e.g. an observer). The longer lived ones are the ones I'm least sure about (e.g. AudioContext, PaymentRequest, message channel stuff). Those would benefit from exploring common code patterns that use those objects, and determining whether inserting using makes sense for them.

Perhaps a relevant point is: in C#, it's generally seen as bad if you don't dispose of something that's IDisposable. Should we similarly envision that on the web, a linter would warn if it saw you creating one of these objects without using? If so then we'd need to be somewhat conservative in how we apply this.

[annevk]

I wonder if this syntax works for https://github.com/fserb/canvas2D/blob/master/spec/layers.md (proposed at whatwg/html#8476). Note that you need some kind of nesting support.

cc @fserb @graveljp

[rbuckton]

I could imagine several approaches:

1. beginLayer returns a disposable that calls endLayer() for you (assuming you can validate the nesting level, or leave it to the user to ensure they don't call .endLayer()):

   const ctx = canvas.getContext('2d');
   {
     using _ = ctx.beginLayer(...); // binding name doesn't matter here
     ctx.fillStyle = 'rgba(225, 0, 0, 1)';
     ctx.fillRect(50, 50, 75, 50);
   } // '_[Symbol.dispose]()' calls 'ctx.endLayer()'

2. Same as above, except you remove endLayer() and depend on the return value of beginLayer():

   const ctx = canvas.getContext('2d');
   {
     using _ = ctx.beginLayer(...); // binding name doesn't matter here
     ctx.fillStyle = 'rgba(225, 0, 0, 1)';
     ctx.fillRect(50, 50, 75, 50);
   } // '_[Symbol.dispose]()' performs compositing against 'ctx'

3. Or, instead have a createLayer() that returns the layer that you manipulate instead:

   const ctx = canvas.getContext('2d');
   {
     using layer = ctx.createLayer(...);
     layer.fillStyle = 'rgba(225, 0, 0, 1)';
     layer.fillRect(50, 50, 75, 50);
   } // 'layer[Symbol.dispose]()' performs compositing against 'ctx'

With any of these options you could still support imperative nesting by using the return value, even without immediately supporting Symbol.dispose:

const ctx = canvas.getContext('2d');
const layer = ctx.beginLayer(...);
ctx.fillStyle = 'rgba(225, 0, 0, 1)';
ctx.fillRect(50, 50, 75, 50);
layer.end(); // which would eventually be aliased by '[Symbol.dispose]()`

[annevk]

Thanks, not entirely sure yet if this ends up helping or not. The other thing I was wondering about is if this influences the name of the proposal as stack management isn't really resource management? At least not how I would typically think of that term.