[int_19h]

In my opinion, having a separate cancellation token that is "threaded through" the call stack is indisposable, because sometimes you need to do more than simply pass along the token that you've got - usually it involves linking several tokens together, e.g. with another representing the state of the component as a whole, as opposed to that particular call chain.

Now, this doesn't happen often, and most of the time you do indeed end up just passing the token along. But when you do need it, it allows for code drastically simpler than any workarounds.

My takeaway from this is that first-class cancellation tokens are the right approach, but languages need some kind of syntactic sugar to eliminate, or at least reduce, the verbiage for the most common case of propagating it around.

(All of this is based on experience working with a heavily async/await codebase written in C# for the past few years.)

[wycats]

> My takeaway from this is that first-class cancellation tokens are the right approach, but languages need some kind of syntactic sugar to eliminate, or at least reduce, the verbiage for the most common case of propagating it around.

That is also my perspective, but I think the syntactic sugar cannot have much more overhead than `async function`.

[int_19h]

The good thing is that it's also a pattern that is highly amenable to syntactic sugar, simply because of how regular it is.

Actually, come to think of it, it is a particular instance of a more common pattern where you receive some state, and propagate it to most (usually, all) further calls that expect it. Scala implicit parameters and variables cover this in the most generic way.