In my opinion the two biggest problems with async today are that it’s missing a standardized API for spawning new threads/tasks (forcing you into picking a particular implementation for something that is pretty fundamental to using async), and there’s no convenient (to say nothing of standardized) way to pin metadata to a Future (E.G. an execution context, or thread-local equivalent). While you can certainly just pass an execution context object around manually it would be nice if there was something baked into Future itself that would prevent that context from cropping up in every method signature.
The new nightly only (and feature flag gated) std::future::join! macro is a nice start, but there’s still more needed (E.G. a mechanism to signal to the underlying implementation that you would prefer some set of Futures be run in parallel if possible). It would also be nice to see a Future variant that supports the concept of retry/repeat out of the box, something like a RestartableFuture.
In my opinion the two biggest problems with async today are that it’s missing a standardized API for spawning new threads/tasks (forcing you into picking a particular implementation for something that is pretty fundamental to using async), and there’s no convenient (to say nothing of standardized) way to pin metadata to a
Future(E.G. an execution context, or thread-local equivalent). While you can certainly just pass an execution context object around manually it would be nice if there was something baked intoFutureitself that would prevent that context from cropping up in every method signature.The new nightly only (and feature flag gated)
std::future::join!macro is a nice start, but there’s still more needed (E.G. a mechanism to signal to the underlying implementation that you would prefer some set ofFutures be run in parallel if possible). It would also be nice to see aFuturevariant that supports the concept of retry/repeat out of the box, something like aRestartableFuture.you know
Futureis a trait, right?