Proposal: Allow Promise callbacks to be removed

[Tab Atkins Jr.]

On Mon, Apr 23, 2018 at 10:56 AM, Oliver Dunk <oliver at oliverdunk.com> wrote:
> My proposal is that we add a way of removing a particular callback, or all callbacks, from a Promise. This is different to cancelling a Promise and would instead happen if you want the operation to continue but are no longer interested in running a function when the Promise is resolved or rejected.
>
> This would be implemented in two ways. The first I believe to be most useful, and the second is a sort of “sub-proposal”, that I would be happy to leave out:
>
> 1. A new `Promise.prototype.clear()` method. This would remove all callbacks currently added to a Promise.

This is almost certainly a no-go - it's a huge capability leak. If
Alice has attached a .then() callback to a promise, Bob shouldn't be
able to cancel that without Alice's permission.

> 2. A `Promise.prototype.clear(promise)` method, which takes the Promise returned when `Promise.prototype.then()` or `Promise.prototype.catch()` was called. This would remove that specific callback leaving any others. I don’t know if another argument would make better sense here? Maybe an identifier to the one used in `clearInterval()`.
>
> The use case that I see for this is for a Promise equivalent to `EventTarget.removeEventListener()`.

Possible, but seems unnecessary. In EventTarget, the listener is
attached *forever*, because there's no limit to how many times the
event can fire. Removing a listener is thus a useful feature, to
prevent listeners from stacking up infinitely.

For a promise, tho, the callback is one-and-done; after it resolves,
the callback is released and can be collected.  There's no strong
memory-related reason to "cancel" a promise callback; if you need that
functionality on your own, you can just have the callback close over a
boolean, and check the boolean once it resolves and either continue or
return immediately.  This would only be a few lines to write a helper
function for.

As others have stated, it also makes the semantics of the returned
promise from .then() unclear. A forever-pending promise is a possible
resolution, but it feels a bit awkward.

~TJ