TC39 member here. cwmma gets a lot right here: Promises have always been contentious in JS (and TC39) and Domenic has indeed had the patience of a saint attemp

TC39 member here. cwmma gets a lot right here: Promises have always been contentious in JS (and TC39) and Domenic has indeed had the patience of a saint attempting to wrangle the various points of view into a coherent proposal. TC39 as a group is generally very motivated to find positive-sum outcomes and find solutions that address everyone's constraints in a satisfactory way. That doesn't usually mean design-by-committee: champions work on a coherent design that they feel hangs together, and the committee provides feedback on constraints, not solutions. As a member of TC39, I'm usually representing ergonomic concerns and the small-company JavaScript developer perspective. I've had a lot of luck, over the years, in giving champions my perspective and letting them come back with an improved proposal. The staging process (which I started sketching out on my blog[1]) has made the back-and-forth easier, which each stage representing further consensus that the constraints of individual members have been incorporated. Unfortunately, I fear that promise cancellation may be a rare design problem with some zero-sum questions. It's worth noting that there has been no objection, on the committee, to adding cancellation to the spec in some form. The key questions have been: First. Is cancellation a normal rejection (a regular exception, like from `throw`) or a new kind of abrupt completion (which `finally` would see but not `catch`). The current status quo on the committee, I believe, is that multiple people would have liked to see "third-state" (as Domenic called it) work, but the compatibility issues with it appear fatal. Second. Should promises themselves be cancelled (`promise.cancel()`) or should there be some kind of capability token threaded through promises. What that would look like: let [sendCancel, recvCancel] = CancelToken.pair(); fetchPerson(person.id, recvCancel); async function fetchPerson(id, token) { // assume fetch is retrofitted with cancel token support let person = await fetch(`/users/${id}`, { token }); } // when the cancel button is clicked, cancel the fetch cancelButton.onclick = sendCancel; This approach had many supporters in the committee, largely because a number of committee members have rejected the idea of `promise.cancel()` (in part because of ideological reasons about giving promise consumers the power to affect other promise consumers, in part because of a problem[2] Domenic raised early about the timing of cancellation, and in part because C# uses cancel tokens[3]). In practice, this would mean that intermediate async functions would need to thread through cancel tokens, which is something that bothered me a lot. For example, it would have this affect on Ember, if we wanted to adopt cancel tokens: // routes/person.js export default class extends Route { async model(id, token) { return fetch(`/person/id`, { token }); } } In other words, any async hook (or callback) would need to manually thread tokens through. In Ember, we'd like to be able to cancel async tasks that were initiated for a previous screen or for a part of the screen that the user has navigated away from. In this case, if the user forgot to take the cancel token (which would likely happen all the time in practice), we would simply have no way to cancel the ongoing async. We noticed this problem when designing ember-concurrency[4] (by the venerable Alex Matchneer), and chose to use generators instead, which are more flexible than async functions, and can be cancelled from the outside. At last week's Ember Face to Face, we discussed this problem, and decided that the ergonomic problems with using cancel tokens in hooks were sufficiently bad that we are unlikely to use async functions for Ember hooks if cancellation requires manually propagating cancel tokens. Instead, we'd do this: // routes/person.js export default class extends Route { *model(id) { return fetch(`/person/id`); } } The `*` is a little more cryptic, but it's actually shorter than `async`, and doesn't require people to thread cancel token through APIs. Also notable: because JavaScript doesn't have overloading (unlike C#), it is difficult to establish a convention for where to put the cancel token ("last parameter", vs. "the name `token` in the last parameter as an options bag" vs. "first parameter"). Because cancellation needs to be retrofitted onto a number of existing promise-producing APIs, no one solution works. This makes creating general purpose libraries that work with "promise-producing functions that can be cancelled" almost impossible. The last bit (since I started talking about Ember) is my personal opinion on cancel tokens. On the flip side, a number of people on the committee have a very strongly held belief that cancel tokens are the only way to avoid leaking powerful capabilities to promise consumers. A third option, making a new Task subclass of Promise that would have added cancellation capabilities, was rejected early on the grounds that it would bifurcate the ecosystem and just mean that everyone had to use Task instead of Promise. I personally think we rejected that option too early. It may be the case that Task is the right general-purpose answer, but people with concerns about leaking capabilities to multiple consumers should cast their Tasks to Promises before passing them around. As I said, I think this may be a (very, very) rare case where a positive-sum outcome is impossible, and where we need, as a committee, to discuss what options are available that would minimize the costs of making a particular decision. Unfortunately, we're not there yet. Domenic has done a great job herding the perspective cats here, and I found his presentations on this topic always enlightening. I hope the committee can be honest enough about the competing goals in the problem of cancellation so that Domenic will feel comfortable participating again on this topic. [1]: https://thefeedbackloop.xyz/tc39-a-process-sketch-stages-0-and-1/ https://thefeedbackloop.xyz/tc39-a-process-sketch-stages-0-a... [2]: https://github.com/tc39/proposal-cancelable-promises/issues/8 https://github.com/tc39/proposal-cancelable-promises/issues/... [3]: https://msdn.microsoft.com/en-us/library/dd997289(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/dd997289(v=vs.110).... [4]: http://ember-concurrency.com/#/docs http://ember-concurrency.com/#/docs