Re: Cancellation architectural observations

>
> //this promise has a way to stop what it is doing
> var p1 = new Promise(function(resolve, reject, ignored){
>   var task = setTimeout(resolve.bind(null, "the result"), 1000);
>   ignored(() => clearTimeout(task));
> });
>

Wouldn't the cancellation token strategy be more appropriate here, for all
the reasons that Dean mentioned?  Something like:

    function delay(ms, { cancellation } = {}) {
        return new Promise(resolve => {
            let id = setTimeout(_=> resolve(), ms);
            if (cancellation) cancellation.then(_=> clearTimeout(id));
        });
    }

(Thanks, Dean, for taking the time to write that up BTW.)

//this promise cannot be cancelled, but the result can be ignored
> var p2 = Promise.resolve("the result");
>
> //the callback is not called until next event loop cycle
> p2.then(result => "this is never called");
>
> //the result is ignored, the above callback is never run
> p2.ignore();
>

It seems like what you want here is to "unregister" the callback, similar
to how you would unregister an event listener.  It seems like that only
makes sense on a callback-by-callback basis, since other callbacks for the
same promise might still want to fire.  Can you not handle this use case
with existing API, plus higher order functions?

    let cbs = forgettable();
    p2.then(cbs(result => "this is never called"));
    cbs.forget();