kicking off concurrency discussions

Hi everyone,

One of the goals for Swift 5 is to start laying the *groundwork* for a concurrency model.


Laying groundwork for a new concurrency model. We will lay groundwork for a new concurrency model, especially as needed for ABI stability. Finalizing such a model, however, is a non-goal for Swift 5. A key focus area will be on designing language affordances for creating and using asynchronous APIs and dealing with the problems created by callback-heavy code.

Concurrency is a topic with many axes of design to explore, as the different domains we wish Swift to be successful will place different demands on a model. That exploration will take time: there will be tradeoffs with any model, and evaluating those tradeoffs will take discussion and iteration.

Today I’d like to open up swift-evolution to start some discussions about concurrency. Some of those discussions will focus on broader designs and concerns, and some will focus on specific use cases which we want to work great in Swift. Some opinions will likely differ significantly in the directions we should take — that’s fine. We intentionally want to explore different design spaces here, as a concurrency model for Swift has far reaching impact in the long-term on Swift as a language.

To kick things off, Chris Lattner has been sharing privately with a few people his own ideas for concurrency, which I have encouraged him to send out after this email. These are just his ideas and **not** an official plan of record, but beyond having some interesting points to discuss I think the way he has framed some of his thinking is a good model for others to follow when bringing up alternate design directions — which I encourage people to do.

Once the Discourse forum comes online (which we are making progress on) we will likely tag or somehow segregate/mark discussions related to concurrency so they can easily be found. For now, one useful trick is to add “[Concurrency]” to the subject line, and when we move to the forum we’ll look to correctly tagging them.



any new updates regarding async/await or coroutines (Coroutines in LLVM), or on this topic

This remains an important direction. A lot of ground work that potentially aligns with this effort went into the effort to bring ABI stability to Apple platforms, such as how property accesses were re-worked to use low-level coroutines. Concurrency, however, was not on the critical path for ABI and module stability and thus hasn't had much direct active work.

Once the Swift 5.1 release wraps up (whose focus is on delivering support for binary frameworks with features like module stability), post Swift 5.1 directions will get more active discussion.


Of course this thread was started because laying the groundwork for concurrency was viewed as a goal for Swift 5. Some of that has happened in part at the low-level as part of the ABI stability effort, but not as much as originally desired made progress on language-level constructs in the Swift 5 timeframe.

Terms of Service

Privacy Policy

Cookie Policy