We posted the first drafts of a number of proposals related to Swift concurrency a few weeks ago. At this time of this writing, the forum topics directly related to the concurrency proposals have more than 600 posts in total (!), which includes lots of great ideas for design improvements, requests for clarification, and so on. We'll have some revised drafts coming up shortly after the U.S. Thanksgiving break that will incorporate a lot of the feedback we've received, which we'll post as separate pitch threads.
In the interim, I'd like to summarize some of that feedback and what we'll be adjusting in the revised proposals. Think of this as an overall summary of various responses from the proposal authors and implementors that are now scattered throughout those 600+ posts. I won't capture all of the discussion, and each item here is intentionally light on detail to give the overall shape of the proposal's evolution. Details will be left to the revised proposals.
Organizational changes to the proposals
The first round of pitches was split across four different proposals (async/await, structured concurrency, actors, and Objective-C interoperability). Even these were large, and will grow as we add more detail, so we'll be splitting out more pieces into separate libraries:
- The task library (currently part of the Structured Concurrency proposal) will become its own proposal.
- Global actors (currently part of the Actors proposal) will become its own proposal.
- Asynchronous handlers (
@asyncHandler) weren't described anywhere, and will become their own proposal.
Specific changes to the proposals
Here are some of the specific changes we will be making for the second pitch:
- Replacing the term "nursery" with "task groups" in the Structured Concurrency proposal.
- Allowing a synchronous actor method to be executed from outside the actor as if it were
async. (The current proposal says that only
asyncmethods can be invoked from outside the actor)
- Banning overloading of
asyncand synchronous methods that otherwise have the same signature (but see the below about overload resolution).
- Removing the ability for an arbitrary class to conform to the
try await; we'll require
await tryto mirror the
async throwsordering on declarations.
- Clarify how concurrent data structures that handle their own locking internally fit into the picture.
- Remove reference to
Important concerns that need further discussion
There are a number of important ongoing discussions about various aspects of the proposals. It is very likely that these discussions will result in changes to the proposal, but none have reached a state where we're ready to adopt specific new wording in the proposal. Some of the higher-impact ones include:
- Actor "re-entrancy", where an
asyncmethod of an actor can suspend and allow other code to execute on that actor, is a nuanced topic. It is likely that some change here will be required, which might involve (e.g.) adding syntax to change the behavior and/or changing the default behavior, but it needs more discussion.
- Providing better actor-isolation guarantees for values passed across actors. The protocol-based actor isolation proposal (pitch #1, pitch #2) is one possible approach here.
- Modeling more concurrency-related aspects in function types, such as "concurrent" and "actor-independent" function types.
- Extending the actor-centric data isolation rules to local variables captured in closures.
reasyncas a complement to
- Allowing an implicit conversion from synchronous functions to
Changes we are not inclined to make
There are a number of proposed changes that were considered and discussed, but which we are not inclined to make. For these, the revised proposals will provide rationale (generally as part of "Alternatives Considered").
We are not inclined to eliminate the overload-resolution rule that prefers
asyncin asynchronous contexts and synchronous functions in synchronous contexts.
We are not inclined to replace
We are not inclined to make
We are not inclined to make
asynca function modifier (e.g.,
async func f()).