Seems pretty reasonable. Any reason to use

new AbortablePromise((resolve, reject, onAbort) => {
  // ...
  onAbort(aborter);
});

instead of

new AbortablePromise((resolve, reject) => {
  // ...
}, aborter);

?

The former gives you access to the original resolve/reject in your aborter. One key feature of this implementation is that abort doesn't automatically imply fulfilled/rejected. Instead, it's still your responsibility resolve/reject.

That makes sense; very interesting.

I wonder why you don't use Bluebird's builtin cancellation mechanism when you extend it's Promise?

Also, your lib doesn't seem to propagate cancellations to child promises:

 fulfilledPromise.then(=> new AbortablePromise(…)).abort();

Here the promise won't be aborted, although it should be.

I do however like the approach that the onAbort handler has the responsibility to call reject if it deems it to be necessary, and does that in the body of the resolver callback to the Promise constructor. In fact, I use a very similar approach in my functional Promise library :-)

I wonder why you don't use Bluebird's builtin cancellation mechanism

The only reason I use Bluebird promises at all is because they're fast on node.js. But when I ship code to the browser, I always use the es6-promise polyfill by swapping out bluebird for es6-promise at build time. So depending on any bluebird-specific behavior (or Q, when, RSVP or whatever) is out for me.

your lib doesn't seem to propagate cancellations to child promises

Only AbortablePromises have the special then, not the other way around. If you're using a non-AbortablePromise we don't have any control over its implementation of then.

@mjackson:

your lib doesn't seem to propagate cancellations to child promises

Only AbortablePromise s have the special then, not the other way around.

However, even if you're chaining two AbortablePromises together then it won't work with your implementation :-/

If you're using a non-AbortablePromise we don't have any control over its implementation of then.

Yeah, that's the reason why we want to spec a common cancellation behaviour and API here :-)

@bergus Ah, I see what you're saying now. Fixed :)

Other guarantees I could make with some small tweaks:

1. the abort handler must resolve or reject
2. the abort handler must not resolve to another promise (seems logical since continuing after abort makes no sense)

I would love to have this feature! I also use es6-promise in the browser, and I use it to wrap http requests. It would be nice to be able to call abort on the promise, and then I can handle calling abort on the request library.

@domenic What would it take to make a formal proposal here?

A formal spec write-up that is implemented in at least one or two of the major promise libraries.