Async/await status?

What’s the current status with Async/await proposal? As far as I know basic building blocks around coroutines exist in swift already, but I guess there’s still lot of work before async/await works in Swift.

Is there something that could be worked on either in code or proposal to get this forward?


I don't understand why this has not been a high priority so far at Apple since Swift is mainly a language for developing client applications.


Probably because there have been items higher on the priority list for a while, ABI Stability being the main culprit. Don't worry, I'm sure they know that it's a highly wished feature.


I think Actors should probably be implemented before Async/Await.

Are there any other languages other than Erlang that have Actor like semantics for dealing with distributed systems?

I think it'd be extremely dubious to try and build actors into the language without async/await primitives already in place.

It's not just Erlang in this context, but any language targeting the OTP, or more specifically, the BEAM VM. So Elixir also follows the same models.

1 Like

The coroutines that Swift implements might not be the best for doing async/await things though. @John_McCall did an excellent talk about coroutines for the 2018 LLVM conference if anyone is curious about them.

  • unidirectional async message sends are great, but inconvenient for some things. We want a model that allows messages to return a value (even if we encourage them not to), which requires a way to wait for that value. This is the point of adding async/await.

"inconvenient" maybe. The BEAM VM (Erlang related?) languages don't have Async/Await from what I can tell.

async/await is just not interesting to me if we don't get actors. Swift would just be playing catch up with C# and JS. Actors is a requirement for better fault tolerance specially on the server. From what I can tell async/await can be added anytime and I don't see why it would have to be a hard requirement for actors. Of course please correct me with evidence if I am wrong.


I think it's a safer bet that Swift is used far more for applications than servers, and async/await is much more useful than actors for application (UI) programming. Actors may be more important to you, but I think it's a hard sell that they're more important to Swift developers as a whole.


Rather than phrase it as an either/or, I think it's good to realize that async/await and actors are complementary features that address different problems:

  • async provides lightweight execution contexts, allowing for more expressive heavily concurrent code.
  • Actors provide lightweight resource contexts, allowing different parts of a program to be isolated from each other so they can fail independently and be more easily reasoned about.

There are definitely synergies, but progress can be made on either independently.


There's no fixed timeline, sorry. If you or anyone else want to continue one of the existing design threads on this topic, or look into the implementation work, you're welcome to.


Are there any other languages other than Erlang that have Actor like semantics for dealing with distributed systems?


(Basis of FoundationDB)

1 Like

I think that with the introduction of "Combine" by Apple, the async/await proposal needs to be adapted to the new reality.

I could imagine that instead of being low-level, async/await moves a bit up and allows to await on Publishers:

// with a Service like this:
protocol MyService {
  func retrieveOne() -> Future<String, Error>

// you might then call it like this:
func invokeService() async {
  do {
    let s = await myService.retrieveOne()
    // do something with s ...
  catch {
    // do something in case of failure ...

func handleButton() {
  beginAsync(scheduler: DispatchQueue.main) {
    await invokeService()

When the async-context is created with a scheduler, an await might implicitly call receive(on:).

For Publishers other than Future, a for s in await myService.retrieveAll() ... syntax might be introduced.

The question might be why to bother with async/await when we could use the fluent style of reactive functional programming.

I think that the reactive style is best to be used when you have a publisher/subscriber relationship which lasts longer (think MVVM) than a single request/response - in which case the async/await style should be preferred instead.


For that to happen Combine needs to be open sourced otherwise it would only be an apple platform specific swift feature which we don‘t want. ;)


Not necessarily: there could be an Awaitable (and MultiAwaitable) protocol which could be adopted by Combine and other frameworks.

But yes, would love to see Combine be part of the Swift OpenSource project - especially as it is somehow sitting between Stdlib and Foundation.

1 Like

Such a protocol would lock down this feature to even a future swift version than Combine was introduced.

I don‘t have any other solutions to offer here, I‘m more interested in the core team finalizing and publishing co-routines that the stdlib itself is already using.

1 Like

Now that Rust has async/await I was reminded that we also have a proposal on this.

Any news here?


While it's great to see that Rust now has async/await it took them a LONG time to get there. There is a fantastic talk about their journey and all of the approaches they have taken over the years here:

Whilst I would love to see Swift with async/await, I don't think it's something that's just around the corner, there is a lot of exploration to be conducted and I believe that the core Swift team is looking into sorting the ownership model first, but I could be mistaken on this.


That's my understanding. As much as I'm looking forward a modern concurrency model in Swift, I don't think we should see anything official until after the Ownership model is fully worked out.

Any news here?

Nothing public no. My guess is that it’ll probably land initially without much warning, like function builders or property wrappers. Property wrappers being a good example of a feature that was previously proposed that came back (somewhat) suddenly. Initially it was proposed as property behaviors, although they accomplish largely similar things.

But all we can do is speculate if there isn’t going to be a community driven effort to get it implemented.