Swift Concurrency Roadmap

[Chris_Lattner3 (Chris Lattner)]

@Ben_Cohen

The end state of these changes will:

• make asynchronous programming convenient and clear at the point of use,
• provide a standard set of language tools and techniques that Swift developers can follow,
• improve the performance of asynchronous code through better knowledge at compile time, and
• eliminate data races and deadlocks in the same way Swift eliminates memory unsafety.

Awesome, I am very excited to see this coming together after so much work over the years on things like exclusivity and the other fundamentals that have gone into this. I'm also happy to see that it is generally aligned with the rough concurrency manifesto outlined earlier. The approach is better in several specific ways than that outline, e.g. the elimination of deadlock is very interesting and could be great (but also needs to be carefully considered, because there are tradeoffs).

@Ben_Cohen

This document outlines a number of proposed additions and changes to the language to achieve this, through the implementation of asynchronous functions and actors.

Also fantastic, I think this is a really great programming model which will lift the programming experience in Swift and provide a strong conceptual foundation for concurrent programming.

@Ben_Cohen

We intend to introduce the features described in this roadmap in two phases: first by introducing the ability to create async functions and actors; and second, by enforcing full actor isolation.

As I related to multiple core team members in previous communication, I think that splitting this into two phases like this (and the proposed approach for the second stage) is extremely concerning for several reasons:

1. A major point of introducing actors is to get rid of shared mutable state -- and the corresponding bugs that go with them. This is the key to providing a safe concurrent programming model, and one of the major failures of actor implementations like Akka. Stage #1 doesn't achieve this.

2. Actors will be adopted by the community very rapidly, and a lot of code will be written against "stage 1" of the design. Doing a hard source break in a subsequent release of the language is going to fracture the community, and cause unnecessary problems for adoption.

3. The proposed "Stage 2" solution to memory isolation (actorlocal, mutableIfUnique, et al) doesn't solve the general use case (it covers a few specific subcases) which means that "stage 2" will be less expressive than "Stage 1". This means that it may be very difficult to adopt even for people who are willing to rewrite their code.

4. The proposed approaches for achieving memory isolation are type system intensive (making the language much more complex), will be difficult to explain to non-super-expert Swift programmers, and will have some fairly concerning semantics implications that may make them not adoptable in general. We should provide a simple model that is easy to explain.

5. The description above makes it sound like you're not interested in the extremely important case data structures that use fine grain locking and lock free structures internally. While I agree that it is good to push programmers (by default) to just use actors to protect shared mutable state, I also think it is important that we allow expert programmers to build powerful libraries that compose with actors correctly.

I believe that there is a simple solution here, which I have been discussing with JohnMC. The description above does a good job of summarizing the two issues, which are cleanly separable:

@Ben_Cohen

Even after the introduction of actors, there will still exist the possibility for race conditions, through global variables and values of reference type:

I will try to find some time this weekend to write the reference type issue up, it seems completely additive to the model proposed here, and will resolve the concerns above. If that is well received, we can talk about globals.

I will also try to review the initial proposal drafts in detail to provide a round of feedback when I can. It is good to see these coming together, but there are a lot of details that will require a significant amount of iteration. While it is super useful to see a draft of these all at once (to understand how they fit together) it will be challenging to keep all the moving parts in my head as the design changes over time. I hope we can serialize some of the formal reviews bottom-up (e.g. starting with async functions).

-Chris