Promise capability support

Isiah Meadows isiahmeadows at
Fri Jul 20 01:13:37 UTC 2018

Sometimes, it's *very* convenient to have those `resolve`/`reject`
functions as separate functions. However, when logic gets complex
enough and you need to send them elsewhere, save a continuation, etc.,
it'd be much more convenient to just have a capability object exposed
more directly rather than go through the overhead and boilerplate of
going through the constructor with all its callback stuff and

It's surprisingly not as uncommon as you'd expect for me to do this:

let resolve, reject
let promise = new Promise((res, rej) => {
    resolve = res
    reject = rej

But doing this repeatedly gets *old*, especially when you've had to
write it several dozen times already. And it comes up frequently when
you're writing lower-level async utilities that require saving promise
state and resolving it in a way that's decoupled from the promise


So here's what I propose:

- `Promise.newCapability()` - This basically returns the result of
[this][1], just wrapped in a suitable object whose prototype is
%PromiseCapabilityPrototype% (internal, no direct constructor). It's
subclass-safe, so you can do it with subclasses as appropriate, too.
- `capability.resolve(value)` - This invokes the implicit resolver
created for it, spec'd as [[Resolve]].
- `capability.reject(value)` - This invokes the implicit rejector
created for it, spec'd as [[Reject]].
- `capability.promise` - This returns the newly created promise.

Yes, this is effectively a deferred API, but revealing constructors
are a bit too rigid and wasteful for some use cases.



Isiah Meadows
me at

More information about the es-discuss mailing list