Why was this proposal withdrawn?

[SEAPUNK]

My apologizes in advance if I've missed something, but it seems this proposal has been abruptly withdrawn without much explanation. Is there a reason why?

[born2net]

my thoughts are that things are being pushed toward rxjs (functional programming, and it is part of TC) thus the reluctance to add features around promises...

[dtipson]

The only true "original" requestor is really the constructor itself. And it, by current design, doesn't expose any external api resulting from the async operation, nor does it yet have a reason to cancel its own operation. The only thing it externally offers is an interface for chaining on things that depend on its eventual state. So either you have to statefully keep track of all of the things later chained onto it (like Bluebird does) or smuggle an out-of-scope hook for cancelation into the scope of the original constructor somehow (like cancel tokens do).

[oallouch]

I personally like the simple Promise/async-await mapping: resolve is the returned value and reject throws an exception...and that's all

[MiracleBlue]

Wishing for domenics speedy recovery, I know just what a toll mental health issues can take on a person. It's tough. Thank you for your hard work.

[benjamingr]

@tarruda no offense, but people who come to the repo and don't read the prior discussion and reading list are causing a real problem and exhaust collaborators. Your whole discussion here in much more depth is available in different documents throughout this repo together with motivating usage examples that show the design decision. In addition this proposal has already majorly changed 3 times and cancellation semantics to reach "consensus" at least 4 times in its existence.

I know you're just trying to help - but this is why people like Domenic get so worn out from this work.

I don't do nearly as much spec work as he does but I feel it too.

[benjamingr]

And everyone dissing Google here for shutting down the proposal without knowing the reasons involved, people stop. It's hurtful.

Google is full of people (Including Domenic btw, who wrote this proposal) and disagreement is taken very seriously. If an implementor won't implement a specification that's a problem for everyone - not just that implementor - it could have just as easily been Mozilla, Microsoft or Apple.

[chrisregnier]

Instead of trying to deal with all the problems associated with adding a cancelled state, why not side step them by working with how promises work right now. Just make Promise.cancel a back propagating resolve/reject?

let p = fetch().then(r => console.log('resolved')).catch(r => console.err('rejected'));
p.cancel('fake response'); // prints 'resolved'
p.cancel(new Error('uhoh')); //prints 'rejected'

The key here is the caller is responsible for what should get passed down the chain, which solves many of the problems posed by whoever cancels things. So cancel(Error) passes the error down the rejection path, a function cancel((resolve, reject) => {}) allows either, and anything else goes down the resolved path.

The other important thing here is that it should work it's way back through the chain until it finds a CancellablePromise, thus allowing a way for multiple consumers to still work properly.

let onCancelled = (cancelledValue, resolve, reject, cancel) => {}
let f = fetch();
let cancellable = f.then(onFulfilled, onRejected, onCancelled);
let c1 = cancellable.then(r => console.log('c1'));
let c2 = cancellable.then(r => console.log('c2'));

c1.cancel(); // passes undefined to onCancelled's cancelledValue and does nothing
f.cancel(); // resolves fetch with undefined, passing it down the chains, eventually prints c1 & c2

And the default onCancelled on non cancellable promises would be (cancelledValue, resolve, reject, cancel) => { cancel(cancelledValue) } which just back propagates the cancelledValue up the chain.

[benjamingr]

@chrisregnier that was this proposal a while ago. See the history and discussions in the git history - for example: https://github.com/tc39/proposal-cancelable-promises/issues/8.

Also please refer to https://github.com/tc39/proposal-cancelable-promises/issues/70#issuecomment-268101606 . Thanks.

People - please, if you have a proposal bring it up at esdiscuss (https://esdiscuss.org/) and not here.

[indolering]

Great recap over at HN:

Promises have always been extremely contentious in JS for a couple reasons and Domenic has had the patience of a saint getting the original proposal through so it's totally understandable that he might not want to deal with this anymore especially if people in his org are against it. There were a couple reasons the original promises were so contentious to standardize.

• Monads: there was a very vocal faction on TC-39 that really wanted a Promises to be monadic and very much emphasized mathematical purity over usefulness and any attempt to discuss things tended to get side tracked into a discussion about monads, see brouhaha over Promise.cast [1].
• Error handling: Promises have a bit of a footgun where by default they can swallow errors unless you explicitly add a listener for them. As you can theoretically add an error listener latter on all other options had downsides (not always obvious to advocates) leading to a lot of arguing, must of it after things had shipped and realistically couldn't be changed. Fixed by platforms and libraries agreeing on a standardization of uncaught promise events [2].
• Just an absurd amount of bike shedding probably the 2nd most bike shedded feature of the spec (behind modules). So cancelable promises reignite all the old debates plus there's no obvious right way to do it, like should it be a 3rd state which could cause compatibility issues and would add complexity, or should cancellations just be a sort of forced rejection, which would be a lot more backwards compatibility but with less features. Additionally there is a bizarre meme that somehow observables (think event emitters restricted to a single event or synchronous streams that don't handle back pressure) are a replacement for promises or are a better fit for async tasks they should be used instead. edit: patients => patience
  1. https://esdiscuss.org/topic/promise-cast-and-promise-resolve
  2. https://gist.github.com/benjamingr/0237932cee84712951a2

@benjamingr Please close this thread and restrict commenting.

[benjamingr]

@indolering I don't have the ability to do so and even if I did - I'm not a TC39 member and would defer to a member anyway. I appreciate the linking to my gist in that comment - it's very nice to be recognized for pushing for things that help people.

[wycats]

I closed comments and restricted to members.