Re: [whatwg/dom] Disposable AbortController (Issue #1405)

bakkot left a comment (whatwg/dom#1405)

I'm only personally advocating for the second case. I am neutral between making this the default behavior of `AbortController` vs adding a new subclass.

Getting a `.abort` when you don't expect it is the sort of thing which tends to be noticeable, whereas _failing_ to `.abort` is often not noticeable (you just needlessly consume additional resources), so I think if we do make `AbortController` itself disposable then having the default behavior be to `.abort` will be less frustrating than having it be to close-without-abort. If someday the close-without-abort functionality is added to `AbortController` we can at that time add a separate `{ disposal: "close-without-abort" }` option to the constructor to opt in to that behavior.

Also, subclass is probably a heavier lift, so if there's implementer interest and I find time to work on this I would make it the default behavior.

I will also note that having `AbortController` be disposable and having that do a `.abort` is, if you squint, kind of like structured concurrency: assuming you pass its signal to every async operation launched from within the scope where you declare the controller, then exiting the scope where you declare the controller will also cancel those operations.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1405#issuecomment-3353410881
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1405/3353410881@github.com>