Skip to content
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
Cannot retrieve contributors at this time


Table of Contents


The Swift concurrency model intends to provide a safe programming model that statically detects data races and other common concurrency bugs. The Structured Concurrency proposal introduces a way to define concurrent tasks and provides data-race safety for functions and closures. This model is suitable for a number of common design patterns, including things like parallel maps and concurrent callback patterns, but is limited to working with state that is captured by closures.

Swift includes classes, which provide a mechanism for declaring mutable state that is shared across the program. Classes, however, are notoriously difficult to correctly use within concurrent programs, requiring error-prone manual synchronization to avoid data races. We want to provide the ability to use shared mutable state while still providing static detection of data races and other common concurrency bugs.

The actor model defines entities called actors that are perfect for this task. Actors allow you as a programmer to declare that a bag of state is held within a concurrency domain and then define multiple operations that act upon it. Each actor protects its own data through data isolation, ensuring that only a single thread will access that data at a given time, even when many clients are concurrently making requests of the actor. As part of the Swift Concurrency Model, actors provide the same race and memory safety properties as structured concurrency, but provide the familiar abstraction and reuse features that other explicitly declared types in Swift enjoy.

Swift-evolution thread: Pitch #1, Pitch #2, Pitch #3.

Proposed solution


This proposal introduces actors into Swift. An actor is a reference type that protects access to its mutable state, and is introduced with the keyword actor:

actor BankAccount {
  let accountNumber: Int
  var balance: Double

  init(accountNumber: Int, initialDeposit: Double) {
    self.accountNumber = accountNumber
    self.balance = initialDeposit

Actors behave like classes in most respects: they can inherit (from other actors), have methods, properties, and subscripts. They can be extended and conform to protocols, be generic, and be used with generics.

The primary difference is that actors protect their state from data races. This is enforced statically by the Swift compiler through a set of limitations on the way in which actors and their instance members can be used, collectively called actor isolation.

Actor isolation

Actor isolation is how actors protect their mutable state. For actors, the primary mechanism for this protection is by only allowing their stored instance properties to be accessed directly on self. For example, here is a method that attempts to transfer money from one account to another:

extension BankAccount {
  enum BankError: Error {
    case insufficientFunds
  func transfer(amount: Double, to other: BankAccount) throws {
    if amount > balance {
      throw BankError.insufficientFunds

    print("Transferring \(amount) from \(accountNumber) to \(other.accountNumber)")

    balance = balance - amount
    other.balance = other.balance + amount  // error: actor-isolated property 'balance' can only be referenced on 'self'

If BankAccount were a class, the transfer(amount:to:) method would be well-formed, but would be subject to data races in concurrent code without an external locking mechanism.

With actors, the attempt to reference other.balance triggers a compiler error, because balance may only be referenced on self. The error message notes that balance is actor-isolated, meaning that it can only be accessed directly from within the specific actor it is tied to or "isolated by". In this case, it's the instance of BankAccount referenced by self. All declarations on an instance of an actor, including stored and computed instance properties (like balance), instance methods (like transfer(amount:to:)), and instance subscripts, are all actor-isolated by default. Actor-isolated declarations can freely refer to other actor-isolated declarations on the same actor instance (on self). Any declaration that is not actor-isolated is non-isolated and cannot synchronously access any actor-isolated declaration.

A reference to an actor-isolated declaration from outside that actor is called a cross-actor reference. Such references are permissible in one of two ways. First, a cross-actor reference to immutable state is allowed because, once initialized, that state can never be modified (either from inside the actor or outside it), so there are no data races by definition. The reference to other.accountNumber is allowed based on this rule, because accountNumber is declared via a let and has value-semantic type Int.

The second form of permissible cross-actor reference is one that is performed with an asynchronous function invocation. Such asynchronous function invocations are turned into "messages" requesting that the actor execute the corresponding task when it can safely do so. These messages are stored in the actor's "mailbox", and the caller initiating the asynchronous function invocation may be suspended until the actor is able to process the corresponding message in its mailbox. An actor processes the messages in its mailbox sequentially, so that a given actor will never have two concurrently-executing tasks running actor-isolated code. This ensures that there are no data races on actor-isolated mutable state, because there is no concurrency in any code that can access actor-isolated state. For example, if we wanted to make a deposit to a given bank account account, we could make a call to a method deposit(amount:) on another actor, and that call would become a message placed in the actor's mailbox and the caller would suspend. When that actor processes messages, it will eventually process the message corresponding to the deposit, executing that call within the actor's isolation domain when no other code is executing in that actor's isolation domain.

Implementation note: At an implementation level, the messages are partial tasks (described by the Structured Concurrency proposal) for the asynchronous call, and each actor instance contains its own serial executor (also in the Structured Concurrency proposal). The serial executor is responsible for running the partial tasks sequentially. This is conceptually similar to a serial DispatchQueue, but the actual implementation in the actor runtime uses a lighter-weight implementation that takes advantage of Swift's async functions.

Compile-time actor-isolation checking determines which references to actor-isolated declarations are cross-actor references, and ensures that such references use one of the two permissible mechanisms described above. This ensures that code outside of the actor does not interfere with the actor's mutable state.

Based on the above, we can implement a correct version of transfer(amount:to:) that is asynchronous:

extension BankAccount {
  func transfer(amount: Double, to other: BankAccount) async throws {
    assert(amount > 0)

    if amount > balance {
      throw BankError.insufficientFunds

    print("Transferring \(amount) from \(accountNumber) to \(other.accountNumber)")

    // Safe: this operation is the only one that has access to the actor's isolated
    // state right now, and there have not been any suspension points between
    // the place where we checked for sufficient funds and here.
    balance = balance - amount
    // Safe: the deposit operation is placed in the `other` actor's mailbox; when
    // that actor retrieves the operation from its mailbox to execute it, the
    // other account's balance will get updated.
    await other.deposit(amount: amount)

The deposit(amount:) operation needs involve the state of a different actor, so it must be invoked asynchronously. This method could itself be implemented as async:

extension BankAccount {
  func deposit(amount: Double) async {
    assert(amount >= 0)
    balance = balance + amount

However, this method doesn't really need to be async: it makes no asynchronous calls (note the lack of await). Therefore, it would be better defined as a synchronous function:

extension BankAccount {
  func deposit(amount: Double) {
    assert(amount >= 0)
    balance = balance + amount

Synchronous actor functions can be called synchronously on the actor's self (or super), but cross-actor references to this method require an asynchronous call. The transfer(amount:to:) function calls it asynchronously (on other), while the following function passGo calls it synchronously (on the implicit self):

actor MonopolyAccount : BankAccount {
  // Pass go and collect $200
  func passGo() {
    super.deposit(amount: 200.0)  // synchronous is okay because `self` is isolated and therefore so is `super`

Cross-actor references to an actor property are permitted as an asynchronous call so long as they are read-only accesses:

func checkBalance(account: BankAccount) {
  print(await account.balance)   // okay
  await account.balance = 1000.0 // error: cross-actor property mutations are not permitted

Rationale: it is possible to support cross-actor property sets. However, cross-actor inout operations cannot be reasonably supported because there would be an implicit suspension point between the "get" and the "set" that could introduce what would effectively be race conditions. Moreover, setting properties asynchronously may make it easier to break invariants unintentionally if, e.g., two properties need to be updated at once to maintain an invariant.

Cross-actor references and Sendable types

SE-0302 introduces the Sendable protocol. Values of types that conform to the Sendable protocol are safe to share across concurrently-executing code. There are various kinds of types that work well this way: value-semantic types like Int and String, value-semantic collections of such types like [String] or [Int: String], immutable classes, classes that perform their own synchronization internally (like a concurrent hash table), and so on.

Actors protect their mutable state, so actor instances can be freely shared across concurrently-executing code, and the actor itself will internally maintain synchronization. Therefore, every actor type implicitly conforms to the Sendable protocol.

All cross-actor references are, necessarily, working with values of types that are being shared across different concurrently-executed code. For example, let's say that our BankAccount includes a list of owners, where each owner is modeled by a Person class:

class Person {
  var name: String
  let birthDate: Date

actor BankAccount {
  // ...
  var owners: [Person]

  func primaryOwner() -> Person? { return owners.first }

The primaryOwner function can be called asynchronously from another actor, and then the Person instance can be modified from anywhere:

if let primary = await account.primaryOwner() { = "The Honorable " +  // problem: concurrent mutation of actor-isolated state

Even non-mutating access is problematic, because the person's name could be modified from within the actor at the same time as the original call is trying to access it. To prevent this potential for concurrent mutation of actor-isolated state, all cross-actor references can only involve types that conform to Sendable. For a cross-actor asynchronous call, the argument and result types must conform to Sendable. For a cross-actor reference to an immutable property, the property type must conform to Sendable. By insisting that all cross-actor references only use Sendable types, we can ensure that no references to shared mutable state flow into or out of the actor's isolation domain. The compiler will produce a diagnostic for such issues. For example, the call to account.primaryOwner() about would produce an error like the following:

error: cannot call function returning non-Sendable type 'Person?' across actors

Note that the primaryOwner() function as defined above can still be used with actor-isolated code. For example, we can define a function to get the name of the primary owner, like this:

extension BankAccount {
  func primaryOwnerName() -> String? {
    return primaryOwner()?.name

The primaryOwnerName() function is safe to asynchronously call across actors because String (and therefore String?) conforms to Sendable.


The restrictions on cross-actor references only work so long as we can ensure that the code that might execute concurrently with actor-isolated code is considered to be non-isolated. For example, consider a function that schedules report generation at the end of the month:

extension BankAccount {
  func endOfMonth(month: Int, year: Int) {
    // Schedule a task to prepare an end-of-month report.
    Task.runDetached {
      let transactions = await self.transactions(month: month, year: year)
      let report = Report(accountNumber: self.accountNumber, transactions: transactions)
      await self.accountOwnerEmailAddress)

A task created with Task.runDetached runs concurrently with all other code. If the closure passed to Task.runDetached were to be actor-isolated, we would introduce a data race on access to the mutable state on BankAccount. Actors prevent this data race by specifying that a @Sendable closure (described in Sendable and @Sendable closures, and used in the definition of Task.runDetached in the Structured Concurrency proposal) is always non-isolated. Therefore, it is required to use asynchronous calls to any actor-isolated declarations.

It is often useful for closures within an actor-isolated function to themselves be actor-isolated, and it is safe from data races so long as the closure itself cannot be executed concurrently with the actor-isolated context in which it occurs. For example, using a sequence algorithm like forEach is free from data races because the closure will only be called serially:

extension BankAccount {
  func close(distributingTo accounts: [BankAccount]) async {
    let transferAmount = balance / accounts.count

    accounts.forEach { account in                        // okay, closure is actor-isolated to `self`
      balance = balance - transferAmount            
      await account.deposit(amount: transferAmount)
    await thief.deposit(amount: balance)

However, not all closure-accepting functions are as well-behaved as the sequence algorithms are. For example, any existing code that provides a completion-handler-based API is problematic:

// not-yet-ported code, probably from a library
extension BankSession {
  func downloadTransactions(accountNumber: Int, since: Date, completionHandler: @escaping ([Transactions], [Date]) -> Void) { ... }

extension BankAccount {
  func updateTransactions() {
    session.downloadTransactions(accountNumber: accountNumber, since: lastUpdatedDate) { (newTransactions, newLastUpdatedDate) in  // problem if this were actor-isolated
      self.transactions.append(contentsOf: newTransactions)
      self.lastUpdateDate = newLastUpdatedDate

Here, BankSession.downloadTransactions is using a completion handler to deliver its results. That completion handler will be called at some later time, but the caller has no knowledge of the actor, so the completion handler can be executed concurrently with actor-isolated code, which would cause a data race. This proposal makes the closure non-isolated in this case, so the references to self.transactions and self.lastUpdateDate will be flagged as an error by actor isolation checking:

error: actor-isolated property 'transactions' can not be referenced by @Sendable closure
error: actor-isolated property 'lastUpdateDate' can not be referenced by @escaping closure

The specific rule determining whether a closure is actor-isolated checks two properties:

  • If the closure is @Sendable or is nested within a @Sendable closure or local function, it is non-isolated, or
  • If the closure is @escaping or is nested within an @escaping closure or a local function, it is non-isolated.

For the examples above:

  • The closure passed to runDetached is non-isolated because it requires a @Sendable function to be passed to it.
  • The closure passed to downloadTransactions is non-isolated because it requires an @escaping function.
  • The closure passed to forEach is actor-isolated to self because it takes a non-sendable, non-escaping function.

Rationale: In theory, @escaping is completely orthogonal to @Sendable, and a Swift program built entirely with @Sendable from the ground up would not have the rule that @escaping closures be non-isolated. However, the existing Swift ecosystem is built without @Sendable, which leaves us with an unfortunate choice. We can assume that the lack of @Sendable on a function type means that the closure won't escape the concurrency domain, and where existing code (i.e., all Swift code that's been written so far) breaks this assumption, we'll have a data race. Or, we can conservatively assume that all existing function types are @Sendable, which will prevent all data races, but at the cost of being unable to use even the most basic facilities (such as, above). Therefore, we employ an heuristic: @escaping is a good (but imperfect) indicator in Swift today that the closure can be executed concurrently, so we don't permit escaping closures to be actor-isolated. This eliminates a significant proportion of the data races that would affect actor state, and the cost of (1) admitting some data races with existing code that manages to execute a closure concurrently without escaping it, and (2) prohibiting some safe patterns where a closure escapes but does not cross concurrency domains. This is a pragmatic, temporarily solution to the problem of rolling out data-race prevention throughout an existing ecosystem. Our approach will ratchet up the safety as code opts in to more concurrency safety in future language versions.

Actor reentrancy

Actor-isolated functions are reentrant. When an actor-isolated function suspends, reentrancy allows other work to execute on the actor before the original actor-isolated function resumes, which we refer to as interleaving. Reentrancy eliminates a source of deadlocks, where two actors depend on each other, can improve overall performance by not unnecessarily blocking work on actors, and offers opportunities for better scheduling of (e.g.) higher-priority tasks. However, it means that actor-isolated state can change across an await when an interleaved task mutates that state, meaning that developers must be sure not to break invariants across an await. In general, this is the reason for requiring await on asynchronous calls, because various state (e.g., global state) can change when a call suspends.

This section explores the issue of reentrancy with examples that illustrate both the benefits and problems with both reentrant and non-reentrant actors, and settles on re-entrant actors. Alternatives Considered provides potential future directions to provide more control of re-entrancy, including non-reentrant actors and task-chain reentrancy.

"Interleaving" execution with reentrant actors

Reentrancy means that execution of asynchronous actor-isolated functions may "interleave" at suspension points, leading to increased complexity in programming with such actors, as every suspension point must be carefully inspected if the code after it depends on some invariants that could have changed before it suspended.

Interleaving executions still respect the actor's "single-threaded illusion", i.e., no two functions will ever execute concurrently on any given actor. However they may interleave at suspension points. In broad terms this means that reentrant actors are thread-safe but are not automatically protecting from the "high level" kinds of races that may still occur, potentially invalidating invariants upon which an executing asynchronous function may be relying on. To further clarify the implications of this, let us consider the following actor, which thinks of an idea and then returns it, after telling its friend about it.

actor Person {
  let friend: Friend
  // actor-isolated opinion
  var opinion: Judgment = .noIdea

  func thinkOfGoodIdea() async -> Decision {
    opinion = .goodIdea                       // <1>
    await friend.tell(opinion, heldBy: self)  // <2>
    return opinion // 🤨                      // <3>

  func thinkOfBadIdea() async -> Decision {
    opinion = .badIdea                       // <4>
    await friend.tell(opinion, heldBy: self) // <5>
    return opinion // 🤨                     // <6>

In the example above the Person can think of a good or bad idea, shares that opinion with a friend, and returns that opinion that it stored. Since the actor is reentrant this code is wrong and will return an arbitrary opinion if the actor begins to think of a few ideas at the same time.

This is exemplified by the following piece of code, exercising the decisionMaker actor:

let goodThink = Task.runDetached { await person.thinkOfGoodIdea() }  // runs async
let badThink = Task.runDetached { await person.thinkOfBadIdea() } // runs async

let shouldBeGood = await goodThink.get()
let shouldBeBad = await badThink.get()

await shouldBeGood // could be .goodIdea or .badIdea ☠️
await shouldBeBad

This snippet may result (depending on timing of the resumptions) in the following execution:

opinion = .goodIdea                // <1>
// suspend: await friend.tell(...) // <2>
opinion = .badIdea                 // | <4> (!)
// suspend: await friend.tell(...) // | <5>
// resume: await friend.tell(...)  // <2>
return opinion                     // <3>
// resume: await friend.tell(...)  // <5>
return opinion                     // <6>

But it may also result in the "naively expected" execution, i.e. without interleaving, meaning that the issue will only show up intermittently, like many race conditions in concurrent code.

The potential for interleaved execution at suspension points is the primary reason for the requirement that every suspension point be marked by await in the source code, even though await itself has no semantic effect. It is an indicator that any shared state might change across the await, so one should avoid breaking invariants across an await, or otherwise depending on the state "before" to be identical to the state "after".

Generally speaking, the easiest way to avoid breaking invariants across an await is to encapsulate state updates in synchronous actor functions. Effectively, synchronous code in an actor provides a critical section, whereas an await interrupts a critical section. For our example above, we could effect this change by separating "opinion formation" from "telling a friend your opinion". Indeed, telling your friend your opinion might reasonably cause you to change your opinion!

Deadlocks with non-reentrant actors

The opposite of reentrant actor functions are "non-reentrant" functions and actors. This means that while an actor is processing an incoming actor function call (message), it will not process any other message from its mailbox until it has completed running this initial function. Essentially, the entire actor is blocked from executing until that task completes.

If we take the example from the previous section and use a non-reentrant actor, it will execute correctly, because no work can be scheduled on the actor until friend.tell has completed:

// assume non-reentrant
actor DecisionMaker {
  let friend: DecisionMaker
  var opinion: Judgment = .noIdea

  func thinkOfGoodIdea() async -> Decision {
    opinion = .goodIdea                                   
    await friend.tell(opinion, heldBy: self)
    return opinion // ✅ always .goodIdea

  func thinkOfBadIdea() async -> Decision {
    opinion = .badIdea
    await friend.tell(opinion, heldBy: self)
    return opinion // ✅ always .badIdea

However, non-entrancy can result in deadlock if a task involves calling back into the actor. For example, let's stretch this example further and have our friend try to convince us to change a bad idea:

extension DecisionMaker {
  func tell(_ opinion: Judgment, heldBy friend: DecisionMaker) async {
    if opinion == .badIdea {
      await friend.convinceOtherwise(opinion)

With non-reentrant actors, thinkOfGoodIdea() will succeed under this implementation, because tell essentially does nothing. However, thinkOfBadIdea() will deadlock because the original decision maker (call it A) is locked when it calls tell on another decision maker (call it B). B then tries to convince A otherwise, but that call cannot execute because A is already locked. Hence, the actor itself deadlocks and cannot progress.

The term "deadlock" used in these discussions refer to actors asynchronously waiting on "each other," or on "future work of self". No thread blocking is necessary to manifest this issue.

In theory, a fully non-reentrant model would also deadlock when calling asynchronous functions on self. However, since such calls are statically determinable to be on self, they would execute immediately and therefore not block.

Deadlocks with non-reentrant actors could be detected with runtime tools that detect cyclic call graphs once they've occurred, much like tools exist to find reference cycles in data structures at runtime. However, such deadlocks cannot generally be identified statically (e.g., with the compiler or static analysis), because call graphs require whole-program knowledge and can change dynamically depending on the data provided to the program.

Deadlocked actors would be sitting around as inactive zombies forever. Some runtimes solve deadlocks like this by making every single actor call have a timeout (such timeouts are already useful for distributed actor systems). This would mean that each await could potentially throw, and that either timeouts or deadlock detection would have to always be enabled. We feel this would be prohibitively expensive, because we envision actors being used in the vast majority of concurrent Swift applications. It would also muddy the waters with respect to cancellation, which is intentionally designed to be explicit and cooperative. Therefore, we feel that the approach of automatically cancelling on deadlocks does not fit well with the direction of Swift Concurrency.

Unnecessary blocking with non-reentrant actors

Consider an actor that handles the download of various images and maintains a cache of what it has downloaded to make subsequent accesses faster:

// assume non-reentrant
actor ImageDownloader { 
  var cache: [URL: Image] = [:]

  func getImage(_ url: URL) async -> Image {
    if let cachedImage = cache[url] {
      return cachedImage
    let data = await download(url)
    let image = await Image(decoding: data)
    return cache[url, default: image]

This actor is functionally correct, whether it is re-entrant or not. However, if it is non-reentrant, it will completely serialize the download of images: once a single client asked for an image, all other clients are blocked from starting any requests--even ones that would hit the cache or which ask for images at different URLs---until that first client has had its image fully downloaded and decoded.

With a reentrant actor, multiple clients can fetch images independently, so that (say) they can all be at different stages of downloading and decoding an image. The serialized execution of partial tasks on the actor ensures that the cache itself can never get corrupted. At worst, two clients might ask for the same image URL at the same time, in which there will be some redundant work.

Existing practice

There are a number of existing actor implementations that have considered the notion or reentrancy:

  • Erlang/Elixir (gen_server) showcases a simple "loop/deadlock" scenario and how to detect and fix it,
  • Akka (Persistence persist/persistAsync is effectively non-reentrant behavior by default, and specific APIs are designed to allow programmers to opt into reentrant whenever it would be needed. In the linked documentation persistAsync is the re-entrant version of the API, and it is used very rarely in practice. Akka persistence and this API has been used to implement bank transactions and process managers, by relying on the non-reentrancy of persist() as a killer feature, making implementations simple to understand and safe. Note that Akka is built on top of Scala, which does not provide async/await. This means that mailbox-processing methods are more synchronous in nature, and rather than block the actor while waiting for a response, they would handle the response as a separate message receipt.
  • Orleans (grains) are also non-reentrant by default, but offer extensive configuration around reentrancy. Grains and specific methods can be marked as being re-entrant, and there is even a dynamic mechanism by which one can implement a run-time predicate to determine whether an invocation can interleave. Orleans is perhaps closest to the Swift approach described here, because it is built on top of a language that provides async/await (C#). Note that Orleans had a feature called call-chain reentrancy, which we feel is a promising potential direction: we cover it later in this proposal in our section on task-chain reentrancy.

Reentrancy Summary

This proposal provides only reentrant actors. However, the Future Directions section describes potential future design directions that could add opt-in non-reentrancy.

Rationale: Reentrancy by default all but eliminates the potential for deadlocks. Moreover, it helps ensure that actors can make timely progress within a concurrent system, and that a particular actor does not end up unnecessarily blocked on a long-running asynchronous operation (say, downloading a file). The mechanisms for ensuring safe interleaving, such as using synchronous code when performing mutations and being careful not to break invariants across await calls, are already present in the proposal.

Protocol conformances

All actor types implicitly conform to a new protocol, Actor:

protocol Actor : AnyObject, Sendable { }

Note: The definition of the Actor protocol is intentionally left blank. The custom executors proposal will introduce requirements into the Actor protocol. These requirements will be implicitly synthesized by the implementation when not explicitly provided, but can be explicitly provided to allow actors to control their own serialized execution.

The Actor protocol can be used to write generic operations that work across all actors, including extending all actor types with new operations. As with actor types, instance properties, functions, and subscripts defined on the Actor protocol (including extensions thereof) are actor-isolated to the self actor. For example,

protocol DataProcessible: Actor {  // only actor types can conform to this protocol
  var data: Data { get }           // actor-isolated to self

extension DataProcessible {
  func compressData() -> Data {    // actor-isolated to self
    // use data synchronously

actor MyProcessor : DataProcessible {
  var data: Data                   // okay, actor-isolated to self
  func doSomething() {
    let newData = compressData()   // okay, calling actor-isolated method on self
    // use new data

func doProcessing<T: DataProcessible>(processor: T) async {
  await processor.compressData() // not actor-isolated, so we must interact asynchronously with the actor

No other kind of concrete type (class, enum, struct, etc.) can conform to the Actor protocol, because they cannot define actor-isolated operations.

Actors can also conform to protocols with async requirements, because all clients will already have to interact with those requirements asynchronously, giving the actor the ability to protect its isolated state. For example:

protocol Server {
  func send<Message: MessageType>(message: Message) async throws -> Message.Reply

actor MyActor: Server {
  func send<Message: MessageType>(message: Message) async throws -> Message.Reply { // okay: this method is actor-isolated to 'self', satisfies asynchronous requirement

Actors cannot otherwise be made to conform to non-Actor protocols with synchronous requirements. However, there is a separate proposal on controlling actor isolation that allows such conformances when they can implemented in a manner that does not reference any mutable actor state.

Detailed design


An actor type can be declared with the actor keyword:

/// Declares a new type BankAccount
actor BankAccount {
  // ...

Each instance of the actor represents a unique actor. The term "actor" can be used to refer to either an instance or the type; where necessary, one can refer to the "actor instance" or "actor type" to disambiguate.

An actor may only inherit from another actor (or NSObject; see the section on Objective-C interoperability below). A non-actor may only inherit from another non-actor.

Rationale: Actors enforce state isolation, but non-actors do not. If an actor inherits from a non-actor (or vice versa), part of the actor's state would not be covered by the actor-isolation rules, introducing the potential for data races on that state.

By default, the instance methods, properties, and subscripts of an actor have an isolated self parameter. This is true even for methods added retroactively on an actor via an extension, like any other Swift type.

extension BankAccount {
  func acceptTransfer(amount: Double) async { // actor-isolated
    balance += amount

Actors are similar to classes in all respects independent of isolation: actor types can have static and class methods, properties, and subscripts. All of the attributes that apply to classes apply to actors in much the same way, except where those semantics conflict with actor isolation.

Actor isolation checking

Any given declaration in a program is either actor-isolated or is non-isolated. A function (including accessors) is actor-isolated if it is defined on an actor type (including protocols where Self conforms to Actor, and extensions thereof). A mutable instance property or instance subscript is actor-isolated if it is defined on an actor type. Declarations that are not actor-isolated are called non-isolated.

The actor isolation rules are checked in a number of places, where two different declarations need to be compared to determine if their usage together maintains actor isolation. There are several such places:

  • When the definition of one declaration (e.g., the body of a function) references another declaration, e.g., calling a function, accessing a property, or evaluating a subscript.
  • When one declaration overrides another.
  • When one declaration satisfies a protocol requirement.

We'll describe each scenario in detail.

References and actor isolation

An actor-isolated non-async declaration can only be synchronously accessed from another declaration that is isolated to the same actor. For synchronous access to an actor-isolated function, the function must be called from another actor-isolated function. For synchronous access to an actor-isolated instance property or instance subscript, the instance itself must be actor-isolated.

An actor-isolated declaration can be asynchronously accessed from any declaration, whether it is isolated to another actor or is non-isolated. Such accesses are asynchronous operations, and therefore must be annotated with await. Semantically, the progam will switch to the actor to perform the synchronous operation, and then switch back to the caller's executor afterward.

For example:

actor MyActor {
  let name: String
  var counter: Int = 0
  func f()

extension MyActor {
  func g(other: MyActor) async {
    print(name)          // okay, name is non-isolated
    print(    // okay, name is non-isolated
    print(counter)       // okay, g() is isolated to MyActor
    print(other.counter) // error: g() is isolated to "self", not "other"
    f()                  // okay, g() is isolated to MyActor
    await other.f()      // okay, other is not isolated to "self" but asynchronous access is permitted


When a given declaration (the "overriding declaration") overrides another declaration (the "overridden" declaration), the actor isolation of the two declarations is compared. The override is well-formed if:

  • the overriding and overridden declarations are isolated to the same actor, or
  • the declarations are both async.

Protocol conformance

When a given declaration (the "witness") satisfies a protocol requirement (the "requirement"), the protocol requirement can be satisfied by the witness if:

  • The requirement is async, or
  • the requirement and witness are both actor-isolated.

An actor can satisfy an asynchronous requirement because any uses of the requirement are asynchronous, and can therefore suspend until the actor is available to execute them. Note that an actor can satisfy and asynchronous requirement with a synchronous one, in which case the normal notion of asynchronously accessing a synchronous declaration on an actor applies. For example:

protocol Server {
  func send<Message: MessageType>(message: Message) async throws -> Message.Reply

actor MyServer : Server {
  func send<Message: MessageType>(message: Message) throws -> Message.Reply { ... }  // okay, asynchronously accessed from clients of the protocol

Partial applications

Partial applications of isolated functions are only permitted when the expression is a direct argument whose corresponding parameter is non-escaping and non-Sendable. For example:

func runLater<T>(_ operation: @escaping () -> T) -> T { ... }

actor A {
  func f(_: Int) -> Double { ... }
  func g() -> Double { ... }
  func useAF(array: [Int]) {                     // okay
    Task.runDetached(operation: self.g)   // error: self.g has non-sendable type () -> Double that cannot be converted to a @Sendable function type
    runLater(self.g)                      // error: self.g has escaping function type () -> Double

These restrictions follow from the actor isolation rules for the "desugaring" of partial applications to closures. The two erroneous cases above fall out from the fact that the closure would be non-isolated in a closure that performs the call, so access to the actor-isolated function g would have to be asynchronous. Here are the "desugared" forms of the partial applications:

extension A {
  func useAFDesugared(a: A, array: [Int]) { { f($0) } )      // okay
    Task.runDetached { g() }   // error: self is non-isolated, so call to `g` cannot be synchronous
    runLater { g() }           // error: self is non-isolated, so the call to `g` cannot be synchronous

Key paths

A key path cannot involve a reference to an actor-isolated declaration:

actor A {
  var storage: Int

let kp = \  // error: key path would permit access to actor-isolated storage

Rationale: Allowing the formation of a key path that references an actor-isolated property or subscript would permit accesses to the actor's protected state from outside of the actor isolation domain. As an alternative to this rule, we could remove the Sendable conformance from key paths, such that one could form key paths to actor-isolated state but they could not be shared.

inout parameters

Actor-isolated stored properties can be passed into synchronous functions via inout parameters, but it is ill-formed to pass them to asynchronous functions via inout parameters. For example:

func modifiesSynchronously(_: inout Double) { }
func modifiesAsynchronously(_: inout Double) async { }

extension BankAccount {
  func wildcardBalance() async {
    modifiesSynchronously(&balance)        // okay
    await modifiesAsynchronously(&balance) // error: actor-isolated property 'balance' cannot be passed 'inout' to an asynchronous function

class C { var state : Double }
struct Pair { var a, b : Double }
actor A {
  let someC : C
  var somePair : Pair

  func inoutModifications() async {
    modifiesSynchronously(&someC.state)        // okay
    await modifiesAsynchronously(&someC.state) // not okay
    modifiesSynchronously(&somePair.a)         // okay
    await modifiesAsynchronously(&somePair.a)  // not okay

Rationale: this restriction prevents exclusivity violations where the modification of the actor-isolated balance is initiated by passing it as inout to a call that is then suspended, and another task executed on the same actor then attempts to access balance. Such an access would then result in an exclusivity violation that will terminate the program. While the inout restriction is not required for memory safety (because errors will be detected at runtime), the default re-entrancy of actors makes it very easy to introduce non-deterministic exclusivity violations. Therefore, we introduce this restriction to eliminate that class of problems that where a race would trigger an exclusivity violation.

Actor interoperability with Objective-C

As a special exception to the rule that an actor can only inherit from another actor, an actor can inherit from NSObject. This allows actors to themselves be declared @objc, and implicitly provides conformance to NSObjectProtocol:

@objc actor MyActor: NSObject { ... }

A member of an actor can only be @objc if it is either async or is not isolated to the actor. Synchronous code that is within the actor's isolation domain can only be invoked on self (in Swift). Objective-C does not have knowledge of actor isolation, so these members are not permitted to be exposed to Objective-C. For example:

@objc actor MyActor: NSObject {
    @objc func synchronous() { } // error: part of actor's isolation domain
    @objc func asynchronous() async { } // okay: asynchronous, exposed to Objective-C as a method that accepts a completion handler
    @objc nonisolated func notIsolated() { } // okay: non-isolated

Source compatibility

This proposal is mostly additive, and should not break source compatibility. The actor contextual keyword to introduce actors is a parser change that does not break existing code, and the other changes are carefully staged so they do not change existing code. Only new code that introduces actors or actor-isolation attributes will be affected.

Effect on ABI stability

This is purely additive to the ABI. Actor isolation itself is a static notion that is not part of the ABI.

Effect on API resilience

Nearly all changes in actor isolation are breaking changes, because the actor isolation rules require consistency between a declaration and its users:

  • A class cannot be turned into an actor or vice versa.
  • The actor isolation of a public declaration cannot be changed.

Future Directions


We could introduce a @reentrant attribute may be added to any actor-isolated function, actor, or extension of an actor to describe how it is reentrant. The attribute would have several forms:

  • @reentrant: Indicates that each potential suspension point within the function bodies covered by the attribute is reentrant.
  • @reentrant(never): Indicates that each potential suspension point within the function bodies covered by the attribute is non-reentrant.

A non-reentrant potential suspension point prevents any other asynchronous call from executing on the actor until it has completed. Note that asynchronous calls to non-reentrant async functions directly on self are exempted from this check, so an actor can asynchronously call itself without producing a deadlock.

Rationale: Allowing direct calls on self eliminates an obvious set of deadlocks, and requires only the same static knowledge as actor-isolation checking for synchronous access to actor-isolated state.

It is an error to have a @reentrant attribute on a non-isolated function, non-actor type, or extension of a non-actor type. Only one @reentrant attribute may occur on a given declaration. The reentrancy of an actor-isolated non-type declaration is determined by finding a suitable @reentrant attribute. The search is as follows:

  1. The declaration itself.
  2. If the declaration is a non-type member of an extension, the extension.
  3. If the declaration is a non-type member of a type (or extension thereof), the type definition.

If there is no suitable @reentrant attribute, an actor-isolated declaration is reentrant.

Here's an example illustrating how the @reentrant attribute can be applied at various points:

actor Stage {
  @reentrant(never) func f() async { ... }    // not reentrant
  func g() async { ... }                      // reentrant

extension Stage {
  func h() async { ... }                      // not reentrant
  @reentrant func i() async { ... }           // reentrant

  actor InnerChild {                          // reentrant, not affected by enclosing extension
    func j() async { ... }                    // reentrant

  nonisolated func k() async { .. }     // okay, reentrancy is uninteresting
  nonisolated @reentrant func l() async { .. } // error: @reentrant on non-actor-isolated

@reentrant func m() async { ... } // error: @reentrant on non-actor-isolated

The attribute approach is not the only possible design here. At an implementation level, the actual blocking will be handled at each asynchronous call site. Instead of an attribute that affects potentially many asynchronous calls, we could introduce a different form of await that does the blocking, e.g.,

await(blocking) friend.tell(opinion, heldBy: self)

Task-chain reentrancy

The discussion of reentrant and non-reentrant actors treats reentrancy as a binary choice, where all forms of reentrancy are considered to be equally likely to introduce hard-to-reason-about data races. However, a frequent and usually quite understandable way of interacting between actors which are simply "conversations" between two or more actors in order fo fulfill some initial request. In synchronous code, it's common to have two or more different classes call back into each other with synchronous calls. For example, here is a silly implementation of isEven that uses mutual recursion between two classes:

class OddOddySync {
  let evan: EvenEvanSync!

  func isOdd(_ n: Int) -> Bool {
    if n == 0 { return true }
    return evan.isEven(num - 1)

class EvenEvanSync {
  let oddy: OddOddySync!

  func isEven(_ n: Int) -> Bool {
    if n == 0 { return false }
    return oddy.isOdd(num - 1)

This code is depending on the two methods of these classes to effectively be "reentrant" within the same call stack, because one will call into the other (and vice-versa) as part of the computation. Now, take this example and make it asynchronous using actors:

actor OddOddy {
  let evan: EvenEvan!

  func isOdd(_ n: Int) async -> Bool {
    if n == 0 { return true }
    return await evan.isEven(num - 1)

actor EvenEvan {
  let oddy: OddOddy!

  func isEven(_ n: Int) async -> Bool {
    if n == 0 { return false }
    return await oddy.isOdd(num - 1)

Under @reentrant(never), this code will deadlock, because a call from EvanEvan.isEven to OddOddy.isOdd will then depend on another call to EvanEvan.isEven, which cannot proceed until the original call completes. One would need to make these methods to be reentrant to eliminate the deadlock.

With Swift embracing Structured Concurrency as a core building block of its concurrency story, we may be able to do better than outright banning reentrancy. In Swift, every asynchronous operation is part of a Task which encapsulates the general computation taking place, and every asynchronous operation spawned from such task becomes a child task of the current task. Therefore, it is possible to know whether a given asynchronous call is part of the same task hierarchy, which is the rough equivalent to being in the same call stack in synchronous code.

We could introduce a new kind of reentrancy, task-chain reentrancy, which allows reentrant calls on behalf of the given task or any of its children. This resolves both the deadlock we encountered in the convinceOtherwise example from the section on deadlocks as well as the mutually-recursive isEven example above, while still preventing reentrancy from unrelated tasks. This reentrancy therefore mimics synchronous code more closely, eliminating many deadlocks without allowing unrelated interleavings to break the high-level invariants of an actor.

There are a few reasons why we are not currently comfortale including task-chain reentrancy in the proposal:

  • The task-based reentrancy approach doesn't seem to have been tried at scale. Orleans documents support for reentrancy in a call chain, but the implementation was fairly limited and it was eventually removed. From the Orleans experience, it is hard to assess whether the problem is with the idea or the specific implementation.
  • We do not yet know of an efficient implementation technique for this approach within the actor runtime.

If we can address the above, task-chain reentrancy can be introduced into the actor model with another spelling of the reentrancy attribute such as @reentrant(task), and may provide the best default.

Alternatives considered

Eliminating inheritance

Like classes, actors as proposed allow inheritance. However, actors and classes cannot be co-mingled in an inheritance hierarchy, so there are essentially two different kinds of type hierarchies. It has been proposed that actors should not permit inheritance at all, because doing so would simplify actors: features such as method overriding, initializer inheritance, required and convenience initializers, and inheritance of protocol conformances would not need to be specified, and users would not need to consider them. The discussion thread on the proposal to eliminate inheritance provides several reasons to keep actor inheritance:

  • Actor inheritance makes it easier to port existing class hierarchies to get the benefits of actors. Without actor inheritance, such porting will also have to contend with (e.g.) replacing superclasses with protocols and explicitly-specified stored properties at the same time.
  • The lack of inheritance in actors won't prevent users from having to understand the complexities of inheritance, because inheritance will still be used pervasively with classes.
  • The design and implementation of actors naturally admits inheritance. Actors are fundamentally class-like, the semantics of inheritance follow directly from the need to maintain actor isolation. The implementation of actors is essentially as "special classes", so it supports all of these features out of the box. There is little benefit to the implementation from eliminating the possibility of inheritance of actors.

Actor inheritance has similar use cases to class inheritance. If we take a textbook example with Person and Employee classes, all the same reasoning applies to actors:

actor Person {
  var name: String
  var birthdate: Date
  // lots of other attributes

actor Employee: Person {
  var badgeNumber: Int

This implementation will behave as one would expect for inheritance (every Employee is-a Person). The inheriting actor type also extends the actor-isolation domain of the actor type it inherits, so (for example) it is safe for a method of Employee to refer to self.birthdate. Given that there are no implementation reasons to disallow inheritance, and the reasons for inheritance of classes apply equally to actors, we retain inheritance for actor types.

Revision history

  • Changes in the seventh pitch:
  • Changes in the sixth pitch:
    • Make the instance requirements of Actor protocols actor-isolated to self, and allow actor types to conform to such protocols using actor-isolated witnesses.
    • Reflow the "Proposed Solution" section to get the bigger ideas out earlier.
    • Remove nonisolated(unsafe).
  • Changes in the fifth pitch:
    • Drop the prohibition on having multiple isolated parameters. We don't need to ban it.
    • Add the Actor protocol back, as an empty protocol whose details will be filled in with a subsequent proposal for custom executors.
    • Replace ConcurrentValue with Sendable and @concurrent with @Sendable to track the evolution of SE-0302.
    • Clarify the presentation of actor isolation checking.
    • Add more examples for non-isolated declarations.
    • Added a section on isolated or "sync" actor types.
  • Changes in the fourth pitch:
    • Allow cross-actor references to actor properties, so long as they are reads (not writes or inout references)
    • Added isolated parameters, to generalize the previously-special behavior of self in an actor and make the semantics of nonisolated more clear.
    • Limit nonisolated(unsafe) to stored instance properties. The prior definition was far too broad.
    • Clarify that super is isolated if self is.
    • Prohibit references to actor-isolated declarations in key paths.
    • Clarify the behavior of partial applications.
    • Added a "future directions" section describing isolated protocol conformances.
  • Changes in the third pitch:
    • Narrow the proposal down to only support re-entrant actors. Capture several potential non-reentrant designs in the Alternatives Considered as possible future extensions.
    • Replaced @actorIndependent attribute with a nonisolated modifier, which follows the approach of nonmutating and ties in better with the "actor isolation" terminology (thank you to Xiaodi Wu for the suggestion).
    • Replaced "queue" terminology with the more traditional "mailbox" terminology, to try to help alleviate confusion with Dispatch queues.
    • Introduced "cross-actor reference" terminology and the requirement that cross-actor references always traffic in Sendable types.
    • Reference @concurrent function types from their separate proposal.
    • Moved Objective-C interoperability into its own section.
    • Clarify the "class-like" behaviors of actor types, such as satisfying an AnyObject conformance.
  • Changes in the second pitch:
    • Added a discussion of the tradeoffs with actor reentrancy, performance, and deadlocks, with various examples, and the addition of new attribute @reentrant(never) to disable reentrancy at the actor or function level.
    • Removed global actors; they will be part of a separate document.
    • Separated out the discussion of data races for reference types.
    • Allow asynchronous calls to synchronous actor methods from outside the actor.
    • Removed the Actor protocol; we'll tackle customizing actors and executors in a separate proposal.
    • Clarify the role and behavior of actor-independence.
    • Add a section to "Alternatives Considered" that discusses actor inheritance.
    • Replace "actor class" with "actor".
  • Original pitch document