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.