rfcs

Some other material that has been written by me on that topic: - Proposal from 2020 about async functions which are forced to run to completion (and thereby would use graceful cancellation if necessary). Quite old, but I still feel that no better idea has come up so far. https://github.com/Matthias247/rfcs/pull/1 - Proposal for unified cancellation between sync and async Rust ("A case for CancellationTokens" - https://gist.github.com/Matthias247/354941ebcc4d2270d07ff0c6...) - Exploration of an implementation of the above: https://github.com/Matthias247/min_cancel_token

As the person who proposed this feature - among lots of other ones for async Rust, like run-to-completion async functions (https://github.com/Matthias247/rfcs/blob/e7fd7042f8069e9126e...), structured concurrency, cancellation tokens, etc) - I can unfortunately share this sentiment. It seemed really hard to land anything in async Rust since the priorities don't seem overly clear. Therefore I put a pause on all contribution attempts and went back to just using Rust as a user.

I assume you mean "spawned futures" - because regular Futures obviously don't have to be 'static. You can run as many of them as you want on a single task by using Future combinators like join/select. If this is mostly about scoped async task and the ability to reference data from the parent task, then there also had been a different proposal being discussed which provides the same guarantee: A new Future type (e.g. CompletionFuture), which by represents an async function that needs to be driven to completion. See https://github.com/Matthias247/rfcs/pull/1 for details. However since this propsal is already 3 years old and hasn't gotten and interest by the Rust async WG, it's probably also not going forward.

>Matthias247 has done work to flesh out what this looks like: https://github.com/Matthias247/rfcs/pull/1 By making a new kind of async function that cannot be called from existing async functions, I see. I started reading it with the expectation that RTCFutures would automatically spawn() themselves to enforce the RTC requirement instead of introducing a third function color. I'm pessimistic a third function color will catch on, but let's see how it goes.

> It knows nothing about what other Futures' poll()s the top-level Future's poll() calls in turn. That's why calling poll would be marked unsafe. When you call poll() manually it's on you to uphold the invariants. > Async-await does not obviate this problem. `let (value, _) = futures::future::select(f1, f2).await.factor_first();` has the same problem, one of the futures is going to be dropped before it resolves. Yes, you also need to reform select. Matthias247 has done work to flesh out what this looks like: https://github.com/Matthias247/rfcs/pull/1