[wycats]

I think it's very likely that we could avoid turning this into a zero-sum debate with one total-winner and one total-loser.

That said, I think there's no positive sum because some folks believe that (1) Promises should be the primary async story in JS, and (2) Promises must not allow communication between two parties who hold a reference to the Promise. This means that `async function`s must return a Promise, and the Promise but not have a `cancel()` method on it (because it would allow communication between two parties holding references to the Promise).

Others (I'll speak for myself here) believe that the return value of `async function` should be competitive (ergonomically) with generators used as tasks (I showed examples in the parent comment). Since generators-as-tasks can be cancelled (via `.return()` and `.throw()`), the desire to make `async function x` as ergonomic as `function* x` conflicts with the goal of disallowing the return value of async functions from being cancellable.

In Ember's case, since generators already exist, it's hard for us to justify asking application developers to participate in an error-prone (and verbose) protocol that we could avoid by using generators-as-tasks instead. And that is likely the conclusion that we will ship (and the conclusion that ember-concurrency has already shipped).

For me, the bottom line is that we have very little budget to introduce new restrictions on `async functions`, because people can always choose to reject async functions and use generators instead (with more capabilities and less typing!). I think the cancellation token proposal is well over-budget from that perspective.