[Concurrency] Asynchronous functions

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

Hi Marcus,

@MarcusSmith

How can an async function be made that interacts with closure-based APIs [...]?

This is covered in the full proposal on structured concurrency, the last section in Structured concurrency: Low-level code and integrating with legacy APis with UnsafeContinuation, please have a look.

@MarcusSmith

[...] or Future based APIs like SwiftNIO?

@MarcusSmith

I'm particularly interested in how async / await works with NIO's EventLoopFuture, because server side swift currently suffers from the same pyramid of death problems noted in the proposal.

Please refer to this thread on NIO adoption of the concurrency features: Future of Swift-NIO in light of Concurrency Roadmap

Long story short: there are a few "steps" in adoption and yes this proposal should solve the "pyramid of doom" issues you allude to in server-side frameworks.

@MarcusSmith

In other languages with async / await, at least ones that I'm familiar with, they all have some kind of Future type that is returned from async functions, which has a clear way of being created from a closure or other future / promise types, but I'm having trouble imagining how it would look when the async nature is part of the function signature but not the return type.

Future values which are free to "pass around" undermine structured-concurrency and thus are a bit discouraged by this design. Please have a look at the structured concurrency design to get a feeling for this.

"Futures" still exist though -- they are called Task.Handle but should be used rarely because they miss out on some cool automatic context/priority/deadline propagation as well as bounded concurrency features.