You pass them to an asynchronous function and said function can do something like `token.throwIfCancelled()` if you've called `token.cancel()` elsewhere.
Doesn't sound as ergonomic as just returning a cancelation function in a future initialiser. Not seeing any other advantages, either. Am I missing some?
Your idea was described by kriskowal in 2013 (see https://github.com/kriskowal/gtor ) - in the promises community we call them "Tasks".
Basically, you can make it work pretty easily with promises and multicast (by reference counting).
The reason they're not added to promises is because some people feel they break a guarantee a promise makes. Not only is it possible - it works well.
Domenic is worn out from having to put up with all the involved shit (if you're reading this, sorry :D). He put a lot of work but I think he's tired of fighting for this rather than push other areas where he meets less resistance in the DOM.
I just wanted to point out that while cancellation is a whole world of complexity and is very interesting - it's not avoided in the language because we're stuck on the technical side.
Interesting! Nice that the approach is known, and others are being discussed. I should check GTOR again.
Multicast cancelation based on refcounting doesn't look right to me. I explicitly avoided this in Posterus, sticking with exclusive ownership, what GTOR calls unicast (thanks for linking). The reason is that subscribers may come and go over time. I've seen, and written, code that caches a promise and reuses it many times. It may start with one consumer, lose it, be canceled, then another consumer comes and gets rejected. This just feels like a big footgun. In Posterus, multicast is explicit and opt-in (`.weak()` futures).
If we eventually standardise a solution, I'd like something with as few interfaces as possible. In a dynamic language, you don't have the luxury of creating a future that initialises into a task, returning a cancelation token. Too many types without static checking is just a footgun. This is part of why Posterus only has futures, why cancelation is provided in the future constructor and tied to the future itself, and why they're eager rather than lazy. Deviating from these constraints would introduce new types, increasing the footgun potential.
Also, I hope I don't sound cocky or rude in my other reply. I have mad respect to people who actually go and build stuff instead of complaining. It's a great way to learn and contribute - and who knows maybe we'll all be using your library in 5 years :D