原文链接：SE-0302 Sendable and @Sendable closures

• Proposal: SE-0302
• Authors: Chris Lattner, Doug Gregor
• Review Manager: John McCall
• Status: Accepted (2021-03-16)
• Implementation: apple/swift#35264
• Major Contributors: Dave Abrahams, Paul Cantrell, Matthew Johnson, John McCall
• Review: (first review) (revision announcement) (second review) (acceptance)

简介

Swift Concurrency 的其中一个关键目标就是“提供一种机制来隔离并发程序中的状态，以消除 data races”。这样的机制将会是通用编程语言的一次重大进步 – 大多数语言提供的并发编程抽象会使程序员面临范围宽广的 bug，包括 race conditions，死锁和其它问题。

这个提案里描述了一种方式，去解决这个领域面临的其中一个问题 – 如何对结构化并发和 Actor 消息传递的值进行类型检查。因此，这是一个统一的理论，它提供了一些基本的类型系统机制，使它们既保障安全又能很好地协同工作。

这种实现方式会提供一个名为 Sendable 的 marker 协议，以及一个可应用于函数的 @Sendable 注解。

背景故事

程序中的每个 actor 实例和结构化并发任务都代表着一个”单线程性的孤岛”（island of single threaded-ness），这使得它们成为一个自然的同步点，持有一系列可变的状态。这些任务与其他任务并行进行计算，但我们希望这样一个系统中的绝大多数代码都是非同步的 – 建立在 actor 的逻辑独立性之上，将其邮箱作为数据的同步点。

因此，一个关键问题是：”我们何时以及如何允许数据在并发域之间传输？” 例如，这种转移发生在 actor 方法调用的参数和返回值中，以及由结构化并发创建的任务中。

Swift Concurrency 的功能渴望建立一个安全而强大的编程模型。我们希望实现这三件事：

1. 我们希望 Swift 程序员在试图 跨并发域传递 可能引入不受保护的共享可变状态 时得到一个静态的编译器错误。
2. 我们希望高阶程序员能够实现包含复杂技术的库（例如 ConcurrentHashTable），并且能够让其他人以一种安全的方式去使用。
3. 我们需要拥抱现有的世界，其中包含了很多在设计时没有考虑到 Swift 并发模型的代码。我们需要一个平滑和渐进的迁移策略。

在我们进入提议的解决方案之前，先看一下我们希望能够建模的一些常见案例，以及每个案例中包含的改进机会和挑战。这将有助于推理出我们需要覆盖的设计空间。

💖 Swift + 值语义

我们需要支持的第一种类型是像 Integer 这样的简单值。这些类型可以简单地跨并发域传递，因为它们不包含指针。

除此之外，Swift 还非常强调具有值语义的类型，这些类型可以安全地跨并发边界传输。除了 class 之外，Swift 的类型组合机制在其元素提供值语义时也提供值语义。这包含了通用的结构，以及其核心集合：例如 Dictionary<Int, String> 就可以直接跨并发域共享。Swift 的 Copy on Write 机制意味着可以在不主动复制数据的情况下传输集合，这是一个非常强大的事实，我相信这将使 Swift 的并发模型在实践中比其他系统更加高效。

然而，这里描述的一切并不简单：当核心集合包含了一般的 class 引用，捕获可变状态的闭包以及其他非值类型时，它们不能安全地跨并发域传输。我们需要一种方法来区分那些 可以安全转移的情况 和 不能安全转移的情况。

值语义的组合

struct、enum 和 tuple 是 Swift 数值组合的主要模式。这些都可以安全地跨并发域传输 – 只要它们包含的数据本身可以安全地传输。

高阶函数编程

在 Swift 和其他具有函数式编程基础的语言中，使用高阶编程是很常见的，即把函数传递给其他函数。Swift 中的函数是引用类型，但许多函数是完全可以跨并发域传递的 – 例如，那些没有捕获变量的函数。

你会有很多很多合理的理由，想要在并发域之间以函数的形式发送计算过程 – 即使是像 parallelMap 这样的微不足道的算法也需要。这在更大规模的计算里也会发生 – 例如，考虑这样一个 actor 的例子：

actor MyContactList {
  func filteredElements(_ fn: (ContactElement) -> Bool) async -> [ContactElement] { … }
}

能够像这样使用：

// 没有捕获变量的闭包是没问题的！
list = await contactList.filteredElements { $0.firstName != "Max" }

// 捕获了一个 `searchName` 字符串变量的闭包也是可以的
// 因为 String 是可以跨并发域传递的
list = await contactList.filteredElements {
  [searchName] in $0.firstName == searchName
}

我们觉得让函数跨并发域传递是很重要的，但是同时我们也有顾虑，我们不应该允许在这些函数中通过引用来捕获本地状态，也不应该允许通过值来捕获不安全的东西。这两者都会带来内存安全问题。

不可变 class

并发编程中一个常见的高效设计模式是建立不可变的数据结构 – 如果一个类中的状态永远不会发生变化，那么在不同的并发域中传输对该类的引用是完全安全的。这种设计模式非常高效（不需要 ARC 以外的同步），可以用来构建高级数据结构，这种模式被纯函数式语言社区广泛采用。

内部同步的引用类型

并发系统中另一种常见的设计模式就是让一个类提供一个“线程安全”的 API：它们用显式同步（mutexes、atomics 等）来保护它们的状态。因为该类的公开 API 可以从多个并发域中安全使用，所以对该类的引用可以安全地直接转移。

对 actor 实例本身的引用就是一个例子：通过传递指针，它们可以在并发域之间安全传递，因为 actor 内部的可变状态是由 actor 邮箱隐式保护的。

在并发域之间”传递”对象

并发系统中的一种相当常见的模式是，一个并发域建立了一个包含非同步的 可变状态的 数据结构，然后通过传输原始指针将其”移交”给另一个并发域使用。如果（也只有在）发送方停止使用已移交的数据时，这在没有同步的情况下也是正确的 – 结果是每次只有发送方或接收方动态地访问可变状态。

既有安全也有不安全的方式来实现这一点，例如，请看最后的其它备选方案部分中关于”奇异的类型系统功能“的讨论。

深拷贝的 Class

转移引用类型的一种安全方式是对数据结构进行深度复制，确保源并发域和目标并发域都有自己的可变状态副本。这对大型结构来说可能很昂贵，但在一些 Objective-C 框架中是或曾经是常用的。一般的共识是，这应该是显式的，而不是隐含在类型定义中的东西。

总结

这只是一些模式的范例，但我们可以看到，有很多不同的并发设计模式在广泛使用。Swift 的设计中心围绕着值类型和鼓励使用 struct 形成了一个非常强大和有利的起点，但是我们也需要能够推导出复杂的情况 – 这既是为了那些希望能够为特定领域编写高性能 API 的社区，也是因为我们需要处理那些 不可能在一夜之间被重写的遗留代码。

因此，允许库作者表达其类型意图的方法是很重要的，应用开发者能够与现有不兼容的库一起相处也是很重要的，而且我们不仅需要提供安全的方式，也需要不安全的方式，这个世界正处于过渡阶段，我们需要在这个不完美的世界里”把任务完成”。

最后，我们的目标是让 Swift（在一般情况下和在这个特定情况下）成为一个高度统一的系统，健全且易于使用。未来 20 年，许多新的库将会基于 Swift 及其最终的并发模型建立。这些库将围绕值语义类型建立，但也应该允许高级程序员部署最先进的技术，如无锁算法，使用不可变类型，或任何其它对他们的领域有意义的设计模式。我们希望这些 API 的用户不必关心它们在内部的实现方式。

解决方案 + 具体设计

这个提案的上层设计围绕着一个名为 Sendable 的 marker 协议，标准库类型将会全面采用 Sendable 协议，以及一个新的 @Sendable 函数注解。

除了基本的提案，在未来，有可能增加一组 Adapter 类型来处理遗留代码的兼容，以及对 Objective-C 框架的一级支持。这些将在下一节中讨论。

Marker 协议类型

本提案将引入 marker 协议的概念，这表明该协议具有某种语义属性，但完全是一个编译时的概念，在运行时没有任何影响。marker 协议有以下限制：

• 它们不能有任何形式的实现要求。
• 它们不能继承非 marker 协议。
• marker 协议不能作为类型使用 is 或 as? 进行检查（例如，x as? Sendable 是一个错误）。
• marker 协议不能用于非 marker 协议的 conditional conformance 约束中。

我们认为这是一个通用的特性，但认为在这一点上它应该是一个编译器内部的特性。因此，我们在下面对它进行了解释，并通过 @_marker 注解语法来表达这个概念。

Sendable 协议

这个提案的核心是 Swift 标准库中定义的一个 marker 协议，它具有特殊的 conformance 检查规则：

@_marker
protocol Sendable {}

当一个类型，其所有的 public API 都被设计成可以安全地跨并发域使用时，让它遵循 Sendable 协议就是个正确的选择。例如，当没有 public mutator 时，或者 public mutator 是用 COW 实现的，亦或者它们是用内部锁或其他机制实现的。类型当然也可以有本地 mutation 的内部实现细节，只要将 lock 或 COW 作为其公共 API 的一部分。

编译器拒绝任何跨并发域传递数据的尝试，例如，actor 消息发送，结构化并发调用的参数或返回值不符合 Sendable 协议，这些情况都会遭到拒绝：

actor SomeActor {
  // async functions are usable *within* the actor, so this
  // is ok to declare.
  // async 函数会在 actor 内部调用的，所以这是可以声明的
  func doThing(string: NSMutableString) async {...}
}

// ... but they cannot be called by other code not protected
// by the actor's mailbox:
// ... 但如果它们从不被 actor 邮箱保护的地方被其它代码调用：
func f(a: SomeActor, myString: NSMutableString) async {
  // error: 'NSMutableString' may not be passed across actors;
  //        it does not conform to 'Sendable'
  await a.doThing(string: myString)
}

Sendable 协议用于建模那些 允许通过复制值在并发域中安全传递的类型。这包括值语义类型、对不可变引用类型的引用、内部同步的引用类型、@Sendable 闭包，以及未来可能的其他类型系统扩展的唯一所有权等。

请注意，对该协议不正确的 conformance 会在你的程序中引入错误（就像对 Hashable 的不正确实现会破坏不变性一样），这就是为什么编译器会检查 conformance（见下文）。

元组的 Sendable conformance

Swift 的元组有特定协议的硬编码 conformance，Sendable 也应该加入到这个规则里，当元组的元素都符合 Sendable 时，元祖也遵循 Sendable。

元类型的 Sendable conformance

元类型（如 Int.Type，由表达式 Int.self 产生的类型）总是遵循 Sendable，因为它们是不可改变的。

struct 和 enum 的 Sendable conformance 检测

Sendable 类型在 Swift 中极为常见，它们的聚合体也可以安全地跨并发域传输。因此，Swift 编译器允许作为其他 Sendable 类型组合出来的 struct 和 class 直接遵循 Sendable：

struct MyPerson : Sendable { var name: String, age: Int }
struct MyNSPerson { var name: NSMutableString, age: Int }

actor SomeActor {
  // struct 和元组可以发送和接收
  public func doThing(x: MyPerson, y: (Int, Float)) async {..}

  // 如果跨 actor 边界被调用就会出错：MyNSPerson 不遵循 Sendable！
  public func doThing(x: MyNSPerson) async {..}
}

虽然这很方便，但我们希望，在需要更加深思熟虑的情况下，稍微增加遵循协议的阻力。因此，当 struct 和 enum 的某个成员（或相关值）本身不符合 Sendable 协议（或通过约束无法推导出是否符合 Sendable 协议）时，编译器会拒绝让其遵循 Sendable 协议。

// error: MyNSPerson cannot conform to Sendable due to NSMutableString member.
// note: add '@unchecked' if you know what you're doing.
struct MyNSPerson : Sendable {
  var name: NSMutableString
  var age: Int
}

// error: MyPair cannot conform to Sendable due to 'T' member which may not itself be a Sendable
// note: see below for use of conditional conformance to model this
struct MyPair<T> : Sendable {
  var a, b: T
}

// 使用 conditional conformance 来建模泛型类型
struct MyCorrectPair<T> {
  var a, b: T
}

extension MyCorrectPair: Sendable where T: Sendable { }

正如在编译器诊断信息里提到的，任何类型都可以通过用 @unchecked 对 Sendable 的 conformance 进行注解，来跳过这种检查行为。这表明该类型可以安全地跨并发域传递，但需要该类型的作者来确保这是安全的。

一个 struct 或 enum 只能在定义该类型的同一个源文件中实现 Sendable 的 conformance。这确保了 struct 中的存储属性和 enum 中的关联值是可见的，这样就可以检查它们的类型是否符合 Sendable。比如说：

// MySneakyNSPerson.swift
struct MySneakyNSPerson {
  private var name: NSMutableString
  public var age: Int
}

// 在另一个源文件或者模块中...
// error: cannot declare conformance to Sendable outside of
// the source file defined MySneakyNSPerson
extension MySneakyNSPerson: Sendable { }

如果没有这个限制，另一个源文件或模块，无法看到私有的存储属性，就会得出结论，MySneakyNSPerson 可以遵循 Sendable。我们也可以将与 Sendable 的遵循声明为 @unchecked 来禁用这个检查：

// 在另一个源文件或者模块中...
// okay: 在另一个源文件的 unchecked 遵循是被允许的
extension MySneakyNSPerson: @unchecked Sendable { }

struct/enum 的 Sendable 隐式 conformance

许多 struct 和 enum 都满足 Sendable 的实现要求，如果需要为每个类型都明确写出 “: Sendable“会让人觉得是太啰嗦。

对于不属于 @usableFromInline 的非 public struct 和 enum，以及 frozen 的 public struct 和 enum，当 conformance 检查（在上一节中描述）成功时，将隐式得遵循 Sendable：

struct MyPerson2 { // 隐式遵循 Sendable
  var name: String, age: Int
}

class NotConcurrent { } // 不遵循 Sendable

struct MyPerson3 { // 不遵循 Sendable 因为 nc 不是 Sendable 的类型
  var nc: NotConcurrent
}

public 的非 fronzen struct 和 enum 不会得到隐式的遵循，因为这样做会给 API resilience 带来问题：对 Sendable 的隐式的遵循会成为与 API 客户端约定的一部分，即使它不是有意的。此外，这种约定可以很容易地被破坏，因为增加 struct 或 enum 的存储属性可能会破坏 Sendable 的遵循。

理由：来自 Hashable、Equatable 和 Codable 的现有先例是要求有显式的 conformance ，即使实现细节会被合成。我们为 Sendable 打破了这个先例，因为(1) Sendable 可能会更加普遍，(2) Sendable 对代码大小（或二进制）没有影响，与其他协议不同，(3) Sendable 除了允许跨并发域使用该类型外，没有引入任何额外的 API。

请注意，对 Sendable 的隐式遵循只适用于非泛型类型和实例数据保证为 Sendable 的泛型类型。例如：

struct X<T: Sendable> {  // 隐式遵循 Sendable
  var value: T
}

struct Y<T> {    // 无法隐式遵循 Sendable 因为 T 不遵循 Sendable
  var value: T
}

Swift 将不会隐式地引入 conditional conformance。这有可能在未来的提案中被引入。

class 的 Sendable conformance 检测

任何 class 都可以被声明为符合 Sendable 的 @unchecked 遵循，允许它们在 actor 之间传递而不需要语义检查。这适用于使用访问权限和内部同步来提供内存安全的类 – 这些机制一般无法通过编译器检查。

此外，一个 class 也许可以遵循 Sendable，并在特定的有限情况下通过编译器检查内存安全：当该 class 是一个 final class，只包含遵循 Sendable 的不可变存储属性：

final class MyClass : Sendable {
  let state: String
}

这样的 class 不能继承于除 NSObject 以外的类（为了 Objective-C 的互操作性）。Sendable class 与 struct 和 enum 有相同的限制，要求 Sendable 的 conformance 写在同一个源文件中。

这种行为使得在 actor 之间安全地创建和传递不可变的共享状态成为可能。在未来，有几种方法可以将其泛化，但有一些不明显的情况需要确定下来。因此，本提案有意保持对 class 的安全检查，以确保我们可以在并发性设计的其他方面取得进展。

Actor 类型

Actor 类型提供它们自己的内部同步，所以它们隐式得遵循 Sendable。actors 提案提供了更多细节。

Key path 字面量

Key path 本身符合 Sendable 协议。然而，为了确保共享 key path 的安全性，key path 字面量只能捕获符合 Sendable 协议的类型的值。这会影响 key path 下标的使用：

class SomeClass: Hashable {
  var value: Int
}

class SomeContainer {
  var dict: [SomeClass : String]
}

let sc = SomeClass(...)

// error: capture of 'sc' in key path requires 'SomeClass' to conform
// to 'Sendable'
let keyPath = \SomeContainer.dict[sc]

新的 @Sendable 函数注解

虽然 Sendable 协议直接针对值类型，并允许 class 选择性地参与并发系统，但函数类型也是重要的引用类型，目前无法遵循协议。Swift 中的函数有几种形式，包括全局 func 声明、嵌套函数、访问器（getters、setters、subscripts 等）和闭包。在可能的情况下，允许函数跨并发域传递，以允许 Swift 并发模型中的高阶函数式编程技术，例如允许定义 parallelMap 和其他明显的并发结构，这是非常实用和重要的。

我们建议在函数类型上定义一个名为 @Sendable 的新注解。一个 @Sendable 函数类型可以安全地跨并发域传输（因此，它隐式得遵循 Sendable 协议）。为了确保内存安全，编译器会对 @Sendable 函数类型的值（例如闭包和函数）进行若干检查：

1. 一个函数可以被标记为 @Sendable。所有捕获的值都必须遵循 Sendable。

2. @Sendable 函数类型的闭包只能使用 by-value 捕获。由 let 引入的不可改变的值的捕获是隐含的 by-value；任何其他捕获的变量必须通过捕获列表指定：

   let prefix: String = ... var suffix: String = ... strings.parallelMap { [suffix] in prefix + $0 + suffix }

   所有捕获的值的类型必须遵循 Sendable。

3. 目前在本提案中，getter/setter 不允许参与 @Sendable 系统。如果有这方面的需求，可以在未来的提案里直接允许 getter 声明为 Sendable。

函数类型的 @Sendable 注解与现有的 @escaping 注解是正交的，但其工作方式是一样的。@Sendable 函数总是非 @Sendable 函数的子类型，并在需要时隐式地进行转换。同样地，闭包表达式从上下文中推断出 @Sendable 位，就像 @escaping 闭包所做的那样。

我们可以重温一下前文提到的例子 – 它可以这样声明：

actor MyContactList {
  func filteredElements(_ fn: @Sendable (ContactElement) -> Bool) async -> [ContactElement] { … }
}

然后可以像这样使用：

// 没有捕获变量的闭包是没问题的！
list = await contactList.filteredElements { $0.firstName != "Max" }

// 捕获了一个 `searchName` 字符串也是没问题的，因为字符串遵循 Sendable
// searchName 是隐式的值捕获
list = await contactList.filteredElements { $0.firstName==searchName }

// @Sendable 是类型的一部分，所以传递一个兼容的函数声明也没问题！
list = await contactList.filteredElements(dynamicPredicate)

// Error: cannot capture NSMutableString in a @Sendable closure!
list = await contactList.filteredElements {
  $0.firstName == nsMutableName
}

// Error: someLocalInt cannot be captured by reference in a
// @Sendable closure!
var someLocalInt = 1
list = await contactList.filteredElements {
  someLocalInt += 1
  return $0.firstName == searchName
}

@Sendable 闭包和 Sendable 类型的组合允许类型安全的并发，它是可扩展的库，同时仍然易于使用和理解。这两个概念都是关键的基础，actor 和结构化并发都建立在其之上。

闭包表达式的 @Sendable 推导

闭包表达式的 @Sendable 注解推导规则与闭包 @escaping 相似。在以下几种情况中，一个闭包表达式将被推导为 @Sendable：

• 它被用于期望有 @Sendable 函数类型的上下文中（例如 parallelMap 或 Task.runDetached）。
• 当 @Sendable 在闭包的 in 前进行指定。

与 @escaping 的区别在于，无上下文的闭包默认为非 @Sendable 的，但默认为 @escaping。

// defaults to @escaping but not @Sendable
let fn = { (x: Int, y: Int) -> Int in x+y }

嵌套函数也是一个重要的考虑因素，因为它们也可以像闭包表达式一样捕获值。嵌套函数声明中使用了 @Sendable 注解来选择加入并发检查：

func globalFunction(arr: [Int]) {
  var state = 42

  // Error, 'state' is captured immutably because closure is @Sendable.
  arr.parallelForEach { state += $0 }

  // Ok, function captures 'state' by reference.
  func mutateLocalState1(value: Int) {
    state += value
  }

  // Error: non-@Sendable function isn't convertible to @Sendable function type.
  arr.parallelForEach(mutateLocalState1)

  @Sendable
  func mutateLocalState2(value: Int) {
    // Error: 'state' is captured as a let because of @Sendable
    state += value
  }

  // Ok, mutateLocalState2 is @Sendable.
  arr.parallelForEach(mutateLocalState2)
}

这对结构化并发和 actor 来说都是干净的组合。

Thrown errors

一个 throws 的函数或闭包可以有效地返回一个符合 Error 协议的任何类型的值。如果该函数从不同的并发域被调用，抛出的值可以被传递到另一个作用域：

class MutableStorage {
  var counter: Int
}
struct ProblematicError: Error {
  var storage: MutableStorage
}

actor MyActor {
  var storage: MutableStorage
  func doSomethingRisky() throws -> String {
    throw ProblematicError(storage: storage)
  }
}

从另一个并发域调用 myActor.doSomethingRisky() 会抛出有问题的 error ，它捕获了 myActor 的部分可变状态，然后提供给另一个并发域，破坏了 actor 的隔离。因为 doSomethingRisky() 的签名中没有关于抛出的 Error 类型的信息，而且从 doSomethingRisky() 传播出来的 error 可能来自该函数调用的任何代码，所以我们没有地方可以检查被抛出的 error 是否遵循 Sendable。

为了修复这个安全漏洞，我们改变了 Error 协议的定义，要求所有的 error 类型都遵循 Sendable。

protocol Error: Sendable { … }

现在，ProblematicError 类型将被编译器拒绝并抛出错误，因为它尝试声明为 Sendable，但包含一个非 Sendable 类型 MutableStorage 的存储属性。

一般来说，在不破坏代码和二进制兼容性的情况下，我们不能在现有的协议上添加新的协议继承。然而，marker 协议对 ABI 没有影响，也没有要求，所以二进制兼容性可以保持。

然而，代码兼容性还是需要更加留意。ProblematicError 在今天的 Swift 中是没有问题的代码，但随着 Sendable 的引入将被拒绝。为了便于过渡，在 Swift < 6 中，通过 Error 获得 Sendable 符合性的类型的错误将被降级为警告。

标准库类型全面添加 Sendable 的 conformance

对于标准库类型来说，跨并发域传递是很重要的。绝大多数标准库类型提供了值语义，因此也应该遵循 Sendable，例如：

extension Int: Sendable {}
extension String: Sendable {}

只要所有泛型参数的类型可以安全地跨并发域传递，泛型的值语义类型就可以安全地跨并发域传递。这种先决条件可以通过 conditional conformance 来进行建模：

extension Optional: Sendable where Wrapped: Sendable {}
extension Array: Sendable where Element: Sendable {}
extension Dictionary: Sendable
    where Key: Sendable, Value: Sendable {}

除了下面列出的情况，标准库中的所有 struct、enum 和 class 的类型都将添加 Sendable 的 conformance。当泛型类型的所有泛型参数都遵循 Sendable 时，它们将有条件地遵循 Sendable。这些规则的例外情况如下：

• ManagedBuffer: 这个类的目的是为一个缓冲区提供可变的引用语义。它不应该遵循 Sendable（甚至不应该跳过检查）。
• unsafe(Mutable)(Buffer)Pointer：这些泛型类型无条件地遵循 Sendable 协议。这意味着一个非并发值的 unsafe pointer 有可能被用来在并发域之间共享这些值。Unsafe 的 pointer 类型从根本上提供了对内存的不安全访问，必须相信程序员能够正确地使用它们；对它们的一个狭窄的维度强制执行严格的安全规则，否则完全不安全的使用似乎与该设计不一致。
• Lazy 算法适配器类型：lazy 算法返回的类型（例如，作为 array.lazy.map { … } 的结果）从不符合 Sendable。许多这样的算法（如 lazy 的 map）采取非 @Sendable 的闭包，因此不能安全地符合Sendable。

译者注：虽然上面提到 unsafePointer 家族的类型都无条件遵循 Sendable 协议，后续的提案 SE-0331 Remove Sendable conformance from unsafe pointer types 移除了这条规则，所以 unsafePointer 家族的类型现在并不遵循 Sendable。

标准库协议 Error 和 CodingKey 都添加 Sendable 协议的继承：

• Error 继承 Sendable，以确保抛出的错误可以安全地跨并发域传递，如上一节所述。
• CodingKey 继承 Sendable，以便像 EncodingError 和 DecodingError 这样存储 CodingKey 实例的类型可以遵循 Sendable。

支持导入 C / Objective-C 的 API

与 C 和 Objective-C 的互操作性是 Swift 的一个重要组成部分。由于 Swift 无法强制强制 C 语言 API 行为正确，因此 C 语言代码对于并发来说总是隐含着不安全的要素。然而，我们仍然通过为许多 C 类型提供隐式 Sendable 遵循来定义与并发模型的一些基本互动：

• C 的 enum 类型总是遵循 Sendable 协议。
• C 的 struct 类型遵循 Sendable 协议，如果它们所有的存储属性都遵循 Sendable。
• C 的函数指针遵循 Sendable 协议。这是很安全的，因为它们无法捕获值。

未来工作 / 后续项目

除了基本提案之外，还有几个后续的东西可以作为后续提案进行探讨。

Adaptor Types for Legacy Codebases

注意。本节不属于提案的一部分 – 包含它只是为了说明设计的各个方面。

上面的提案为组合和 Swift 类型提供了良好的支持，这些类型将被更新以支持并发。此外，Swift 对跳过协议遵循的支持，让用户可以使用尚未更新的遗留代码库。

然而，在与现有框架的兼容性方面，还有一个重要的问题需要面对：框架有时是围绕着具有特殊结构的可变对象密集图设计的。虽然最终能”重写整个世界”是件好事，但实际工作中 Swift 程序员需要得到支持，以便在这期间”将工作完成”。

举个例子，当 Swift 刚出来的时候，大多数 Objective-C 框架都没有对 nullability 进行审核。我们引入了 “ImplicitlyUnwrappedOptional“ 来处理过渡期的问题，随着时间的推移，它优雅地淡出了使用范围。

为了说明我们如何在 Swift Concurrency 中做到这一点，请考虑 Objective-C 框架中常见的一种模式：通过跨线程”转移”引用来传递一个对象图 – 这很有用，但不符合内存安全！程序员会希望能够在他们的应用程序中把这些东西作为 actor API 的一部分来表达。

这可以通过引入一个通用的 helper struct 来实现：

@propertyWrapper
struct UnsafeTransfer<Wrapped> : @unchecked Sendable {
  var wrappedValue: Wrapped
  init(wrappedValue: Wrapped) {
    self.wrappedValue = wrappedValue
  }
}

例如，NSMutableDictionary 在跨并发域传递时并不安全，所以它没办法安全得遵循 Sendable。上面的 struct 允许你（作为应用程序的程序员）像这样写一个 actor 的 API：

actor MyAppActor {
  // The caller *promises* that it won't use the transferred object.
  public func doStuff(dict: UnsafeTransfer<NSMutableDictionary>) async
}

虽然这不是特别优雅，但当你需要处理未经审计和不安全的代码时，它能有效地在调用者一方完成工作。这也可以使用最近提出的将 propertyWrapper 拓展到函数参数，变成一个参数属性，允许一种更优雅的声明和调用方语法：

actor MyAppActor {
  // The caller *promises* that it won't use the transferred object.
  public func doStuff(@UnsafeTransfer dict: NSMutableDictionary) async
}

Objective-C 框架支持

注意。本节不属于是提案的一部分 - 它只是为了说明设计的各个方面。

Objective-C 已经建立了一些模式，可以合理地融入到这个框架里，例如，NSCopying 协议是一个重要的、被广泛采用的协议，应该被纳入这个框架。

一般的共识是，在模型中明确复制是很重要的，所以我们可以像这样实现一个 NSCopied helper：

@propertyWrapper
struct NSCopied<Wrapped: NSCopying>: @unchecked Sendable {
  let wrappedValue: Wrapped

  init(wrappedValue: Wrapped) {
    self.wrappedValue = wrappedValue.copy() as! Wrapped
  }
}

这将允许 actor 方法的个别参数和结果选择使用一个单独的副本：

actor MyAppActor {
  // The string is implicitly copied each time you invoke this.
  public func lookup(@NSCopied name: NSString) -> Int async
}

一个粗略的解释：Objective-C 的静态类型系统在这里对我们的 immutability 帮助不大：静态类型的 NSString 由于可以被继承，所以实际上可能是动态的 NSMutableString。正因为如此，我们无法假设 NSString 类型的值是动态不可变的 – 它们应该在实现里调用 copy() 方法。

和 actor self 与 @Sendable 闭包的交互

Actor 是基于这个提案之上提出的，但了解 actor 的设计也很重，以确保本提案能满足其需求。如上所述，actor 方法跨越并发边界的发送，要求参数和结果遵循 Sendable，因此隐含着一个要求，跨越这种边界传递的闭包必须是 @Sendable 的。

还有一个需要解决的细节是”什么时候算是跨 actor 的调用？”。例如，我们希望这些调用是同步的，不需要 await：

extension SomeActor {
  public func oneSyncFunction(x: Int) {... }
  public func otherSyncFunction() {
    // No await needed: stays in concurrency domain of self actor.
    self.oneSyncFunction(x: 42)
    oneSyncFunction(x: 7)    // Implicit self is fine.
  }
}

然而，我们也需要考虑当 self 被捕获到 actor 方法中的闭包时的情况。比如说：

extension SomeActor {
  public func thing(arr: [Int]) {
    // This should obviously be allowed!
    arr.forEach { self.oneSyncFunction(x: $0) }

    // Error: await required because it hops concurrency domains.
    arr.parallelMap { self.oneSyncFunction(x: $0) }

    // Is this ok?
    someHigherOrderFunction {
      self.oneSyncFunction(x: 7)  // ok or not?
    }
  }
}

我们需要编译器知道是否有一个可能的并发域跳转 – 如果有，就需要一个 await。幸运的是，这可以通过上述基本类型系统规则的直接组合来实现。在 actor 方法的非 @Sendable 闭包中使用 actor self 是完全安全的，但是在 @Sendable 闭包中使用它将被视为来自不同的并发域，因此需要一个 await。

Marker 协议作为一个自定义注解

marker 协议 Sendable 和函数注解 @Sendable 被故意赋予相同的名字。这里有一个潜在的未来方向，即 @Sendable 可以从一个被编译器识别的特殊注解（如这个提议），类似 Sendable 这样使用一个通用的 marker 协议机制，成为自定义属性，如 propertyWrapper 和 resultBuilder。这样的改变对使用 @Sendable 现有的代码影响很小，只要用户不声明他们自己的 Sendable 类型，不与标准库中的类型同名。然而，它将使 @Sendable 不再特殊，并允许其他 marker 协议以类似的方式使用。

代码兼容性

这几乎与现有的代码库完全代码兼容。引入 Sendable marker 协议和 @Sendable 函数注解是附加功能，不使用时没有影响，因此不会影响现有代码。

但这里有一些新的限制，在特殊情况下可能会导致代码兼容性破坏：

• 对 keypath 字面量下标的改变将破坏用非标准类型索引的外部 keypath。
• Error 和 CodingKey 将添加 Sendable 的继承，因此要求自定义 Error 和 CodingKey 符合 Sendable。

由于这些修改，新的限制将只在 Swift 6 模式下执行，但对于 Swift 5 和更早的版本将是警告。

对 API resilience 的影响

这项建议对 API 的弹性没有任何影响!

其它备选方案

在讨论这个提案时，有几个备选方案也是很有意义的。在这里，我们尝试讨论一些较大的问题。

奇异的类型系统功能

Swift Concurrency Roadmap 提到，未来的功能集迭代可能会引入新的类型系统特性，如 “mutableIfUnique“ 类，而且很容易想象，move 语义和唯一所有权有一天会被引入 Swift。

虽然在不了解未来提案完整规范的情况下，很难理解详细的交互逻辑，但我们相信执行 Sendable 检查的检查机制是简单和可组合的。它应该适用于任何可以安全跨越并发边界的类型。

支持一种显式的 copy hook

本提案的第一次修订允许类型在跨并发域发送时自定义行为，通过实现 unsafeSend 协议要求。这增加了提案的复杂性，添加了不必要的功能（明确实现的复制行为），使递归聚合的情况消耗更多性能，并且会导致更大的代码二进制文件。

总结

这项提案引入了一种非常简单的方式，用于定义可以安全地跨并发域传输的类型。它需要的编译器/语言支持很少，与现有的 Swift 功能一致，可由用户扩展，与传统的代码库一起使用，并提供了一个简单的模型，即使在 20 年后我们也会觉得很棒。

因为该功能主要是建立在现有语言支持基础上的库功能，所以很容易定义包装类型，为特定领域的关注点进行扩展（按照上面 NSCopied 的例子），跳过遵循检查使用户很容易与尚未更新以了解 Swift 并发模型的旧库合作。

修订历史

• Changes from the second review:
  • Renamed @sendable to @Sendable, per review feedback and Core Team decision.
  • Add a future direction on marker protocols as custom attributes.
  • Removed “Swift Concurrency 1.0” and “2.0” discussion in Alternatives Considered.
• Changes from the first review
  • Renamed ConcurrentValue to Sendable and @concurrent to @sendable.
  • Replaced UnsafeConcurrentValue with @unchecked Sendable conformances.
  • Add implicit conformance to Sendable for non-public, non-frozen struct and enum types.

原文链接：SE-0306 Actors

• Proposal: SE-0306
• Authors: John McCall, Doug Gregor, Konrad Malawski, Chris Lattner
• Review Manager: Joe Groff
• Status: Implemented (Swift 5.5)
• Decision Notes: Acceptance, First Review, Second Review
• Implementation: Partially available in recent main snapshots behind the flag -Xfrontend -enable-experimental-concurrency

简介

Swift 并发模型计划提供一个安全的编程模型，静态地检测 data-races 和其他常见的并发错误。结构化并发提案引入了一种定义并发任务的方法，并为函数和闭包提供了安全的 data-race。这个模型适用于许多常见的设计模式，包括像 parallel maps 和并发回调模式，但只限于处理由闭包捕获的状态。

Swift 包含了 class，它提供了一种机制来声明整个程序共享的 mutable 状态。然而，class 在并发程序中难以正确使用，需要手动同步来避免 data race，很容易出错。我们希望提供这么一种功能，在使用共享的 mutable 状态的同时，仍然提供对 data race 和其他常见并发 bug 的静态检测。

Actor 模型定义了称为 actors 的实体，这些实体非常适合这项任务。Actor 允许你，作为一个程序员，声明一系列的状态，这些状态由一个 concurrency domain 持有，并且可以定义多个对其的操作。每个 actor 通过 data isolation 来保护自己的数据，确保在给定时间内只有一个线程访问它的数据，即使许多用户同时向 actor 发出请求。作为 Swift 并发模型的一部分，actor 提供了与结构化并发相同的 race 和内存安全属性，但也提供了 Swift 中其他显式声明的类型所享有的熟悉的抽象和复用的特性。

Swift-evolution threads:

• Pitch #1,
• Pitch #2,
• Pitch #3,
• Pitch #4,
• Pitch #5,
• Pitch #6,
• Review #1

解决方案

Actors

这项提案将引入 actors。Actor 是一种引用类型，可以保护它的 mutable state 的访问，通过关键字 actor 引入：

actor BankAccount {
  let accountNumber: Int
  var balance: Double

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

就像其它的 Swift 类型，actor 可以有构造器、方法、属性和下标。它们可以被扩展并遵循协议，可以是泛型，也可以与泛型一起使用。

最主要的区别是，actor 会保护其状态不受 data-race 影响。这一点会由 Swift 编译器静态地强制执行，通过对 actor 及其实例成员的使用方式进行一系列限制，这些限制统称为 actor isolation。

Actor 隔离

Actor isolation 是 actor 保护其可变状态的方式。对于 actor 来说，这种保护的主要机制是只允许实例的存储属性通过 self 访问。例如，这里有一个方法，试图将钱从一个账户转到另一个账户：

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'
  }
}

如果 BankAccount 是一个 class，transfer(amount:to:) 方法就是定义正确的，但在没有外部加锁的并发代码中会出现 data race。

使用 actor 时，试图访问 other.balance 会引发编译错误，因为 balance 只能通过 self 访问。错误信息指出 balance 是隔离在 actor 里的，意味着它只能从它被绑定或”隔离”的特定 actor 中直接访问。在这个例子中，它是由 self 引用的 BankAccount 的实例。所有关于 actor 实例的声明，包括存储和计算的实例属性（如 balance）、实例方法（如transfer(amount:to:)）和实例下标，默认都是被 actor 隔离的。Actor 隔离的声明可以自由地引用同一 actor 实例上的其他被 actor 隔离的声明（通过 self）。任何没有被 actor 隔离的的声明都是不被隔离的，不能同步访问任何被 actor 隔离的声明。

在一个 actor 之外对该 actor 隔离的声明的引用被称为跨 actor 引用，这种引用有两种方式是合法的。

第一，对不可变的状态的跨 actor 引用是合法的，因为一旦初始化，该状态就不能被修改（无论是从 actor 内部还是外部），所以从定义上来说没有数据竞争。根据这个规则，对 other.accountNumber 的引用是允许的，因为 accountNumber 是通过一个 let 声明的，并且具有值语义类型 Int。

第二种合法的跨 actor 引用的形式是用异步函数调用。这种异步函数调用会被转化为”消息”，actor 会在可以安全地执行的时候，执行相应的任务。这些消息会存储在 actor 的”邮箱”中，启动异步函数调用的调用者可能被暂停，直到 actor 能够处理其邮箱中的相应消息。Actor 按顺序处理其邮箱中的消息，因此，一个给定的 actor 将永远不会有两个同时执行的任务，运行 actor 隔离的代码。这确保了在 actor 隔离的可变状态上不会有数据竞赛，因为在任何可以访问 actor 隔离的状态的代码中都没有并发性。例如，如果我们想给一个给定的银行账户 account 存款，我们可以调用另一个 actor 上的方法 deposit(amount:)，这个调用将成为一个放在该 actor 邮箱中的消息，调用者将暂停。当该 actor 处理消息时，它最终会处理与存款相对应的消息，当没有其他代码在该 actor 的隔离域中执行时，就在该 actor 的隔离域中执行该调用。

实现说明。在实现层面上，消息是异步调用的 partial task（由结构化并发提案描述），每个 actor 实例包含自己的 serial executor（也在结构化并发提案中）。Serial executor 负责按顺序运行部分任务。这在概念上类似于一个串行的 DispatchQueue，但在 actor 运行时的实际实现中使用了一个更轻量级的实现，利用了 Swift 的 async 函数。

编译时 actor-isolation 检查会确定哪些对被 actor 隔离的声明引用是跨 actor 的引用，并确保这种引用使用上述两种允许的机制之一。这确保了 actor 之外的代码不会干扰 actor 的 mutable 状态。

基于上述，我们可以实现一个正确的 transfer(amount:to:) 版本，它是异步的：

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)")

    // 安全：这是当前唯一一个访问被 actor 隔离的状态的操作，并且
    // 在我们检查是否有足够的资金之后，执行到这里的逻辑之前，中间没有
    // 任何暂停点。
    balance = balance - amount
    
    // 安全：存款的操作会被放到 `other` actor 的邮箱里；
    // actor 会从邮箱里取出这个操作并且执行它，other 的
    // 账户余额将会被更新。
    await other.deposit(amount: amount)
  }
}

deposit(amount:) 操作需要涉及不同 actor 的状态，所以必须异步调用。这个方法本身可以被实现为 async：

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

然而，这个方法其实并不需要是 async：它没有进行异步调用（注意这里没有 await）。因此，它最好被定义为一个同步函数：

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

同步的 actor 函数可以在 actor 的 self 上同步调用，但是跨 actor 引用这个方法需要异步调用。transfer(amount:to:) 函数异步调用它（在 other 上），而下面的函数 passGo 同步调用它（在隐式 self 上）。

extension BankAccount {
  // Pass go and collect $200
  func passGo() {
    self.deposit(amount: 200.0)  // synchronous is okay because `self` is isolated
  }
}

只要是只读访问，就允许跨 actor 对 actor 属性的引用作为异步调用：

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

理由：支持跨 actor 的属性设置是可能的。然而，不能合理地支持跨 actor 的 inout 操作，因为在 get 和 set 之间会有一个隐含的暂停点，可能会引入有效的竞赛条件。此外，异步设置属性可能会使其更容易无意中破坏不变性，例如，两个属性需要同时更新以保持不变性。

从 module 外，不可变的 let 必须从 actor 外异步引用。比如说：

// From another module
func printAccount(account: BankAccount) {
  print("Account #\(await account.accountNumber)")
}

这保留了定义 BankAccount 的模块将 let 演变为 var 而不破坏客户端的能力，这是 Swift 一直保持的特性：

actor BankAccount { // version 2
  var accountNumber: Int
  var balance: Double  
}

accountNumber 改为 var 之后，只有 module 内的代码需要改变；现有的客户端使用已经是异步访问，不受影响。

跨 actor 引用和 Sendable 类型

SE-0302 介绍了 Sendable 协议。符合 Sendable 协议的类型的值可以在并发执行的代码中安全地共享。有各种各样的类型以这种方式工作：像 Int 和 String 这样的值语义类型，像 [String] 或 [Int: String] 这样的值语义集合，immutable 的 class，内部执行自己同步的类（例如 ConcurrentHashMap），等等。

Actor 会保护它的 mutable 状态，所以 actor 实例可以在并发执行的代码中自由共享，而且 actor 本身将在内部保持同步。因此，每个 actor 类型都隐式遵循 Sendable 协议。

所有的跨 actor 引用都，必须，与在并发执行的代码中共享的值一起使用。例如，假设我们的 BankAccount 包括一个所有者列表，每个所有者都建模为 Person 类：

class Person {
  var name: String
  let birthDate: Date
}

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

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

primaryOwner 函数可以从另一个 actor 中异步调用，然后可以从任何地方修改 Person 实例。

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

即使是 non-mutating 的访问也是会有问题的，因为在原始调用试图访问这个 Person 的时候，这个 Person 的 name 也可能从 actor 内部被修改。为了防止这种被 actor 隔离的状态的并发 mutate 的可能性，所有的跨 actor 引用只能涉及符合 Sendable 的类型。对于一个跨 actor 的异步调用，参数和返回值类型必须符合 Sendable。对于一个跨 actor 的不可变属性引用，属性类型必须符合 Sendable。通过坚持所有的跨 actor 引用只使用 Sendable 类型，我们可以确保对共享 mutable 状态的引用不会流入或流出 actor 的隔离域。编译器会对这类问题进行诊断。例如，对 account.primaryOwner() 的调用会产生类似以下的错误。

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

请注意，上面定义的 primaryOwner() 函数仍然可以用于被 actor 隔离的代码。例如，我们可以定义一个函数来获取 primary owner 的名字，像这样：

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

primaryOwnerName() 函数可以安全地跨 actor 异步调用，因为 String（因此也包括String?）符合Sendable。

闭包

对跨 actor 引用的限制，只有在我们能确保，可能与被 actor 隔离的代码同时执行的代码，被视为不被隔离的情况下才有效。例如，一个计划生成月末报告的函数：

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

用 detach 创建的任务会与所有其他代码同时运行。如果传递给 detach 的闭包是被 actor 隔离的，我们将在访问 BankAccount 的 mutable 状态时引入 data race。actor 通过指定 @Sendable 闭包总是不被隔离的，来防止这种数据竞赛（在 Sendable 和 @Sendable 闭包中描述，并在结构化并发提案中用于 detach 的定义）。因此，它需要异步访问任何被 actor 隔离的声明。

一个不是 @Sendable 的闭包不能脱离它所形成的并发域。因此，如果这样的闭包是在一个被 actor 隔离的上下文中形成的，那么它将是被 actor 隔离的。这一点很有用，例如，当应用在 forEach 这样的 Sequence 算法时，所提供的闭包将被连续调用：

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)
  }
}

在一个被 actor 隔离的上下文中形成的闭包，如果它是非 @Sendable，则是被 actor 隔离的，如果它是 @Sendable，则是不被隔离的。对于上面的例子：

• 传递给 detach 的闭包是不被隔离的，因为该函数需要传递一个 @Sendable 闭包给它。
• 传递给 forEach 的闭包是与 self 隔离的，因为它需要一个非 @Sendable 函数。

Actor 重入

被 actor 隔离的函数是可重入的。当一个被 actor 隔离的函数暂停时，可重入性允许其他工作在原本被 actor 隔离的函数恢复之前，在该 actor 上执行，我们称之为 interleaving（交织执行）。重入消除了一个死锁的来源，即两个 actor 相互依赖，可以通过减少 actor 非必要的阻塞，来提高整体性能，并为更好地调度（例如）优先级更高的任务提供机会。然而，这意味着当交织的任务修改状态时，被 actor 隔离的状态可能会跨 await 发生变化，这意味着开发者必须确保不打破跨 await 的不变性。一般来说，这是在异步调用中要求 await 的原因，因为当调用暂停时，各种状态（例如全局状态）会发生变化。

本节会通过例子探讨重入问题，阐述重入 actor 和非重入 actor 的好处和问题，并最终确定使用重入 actor。Alternatives Considered 提供了潜在的未来方向，以提供对重入的更多控制，包括非重入 actor 和任务链重入。

可重入 actor 的交织执行

重入意味着异步被 actor 隔离的函数的执行可能会在暂停点上交织，导致用这种 actor 编程的复杂度增加，因为如果暂停点之后的代码依赖于一些可能在暂停前发生变化的不变量，则必须仔细检查每个暂停点。

交织执行仍然尊重 actor 的”单线程幻觉”，也就是说，没有两个函数会在任何给定的 actor 上并发地执行。然而，它们可以在暂停点上交织。从广义上讲，这意味着可重入 actor 是线程安全的，但无法自动保护状态，因为”上层”的数据竞赛仍然可能发生，有可能使执行中的异步函数所依赖的不变性失效。为了进一步说明这个问题的含义，让我们看看下面这个 actor，它想到了一个想法，然后在告诉它的朋友之后将其返回：

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>
  }
}

在上面的例子中，Person 可以想到一个好的或坏的想法，与一个朋友分享这个意见，并返回它所存储的意见。由于 actor 是可重入的，所以这段代码是错误的，如果 actor 同时开始思考几个想法，就会返回一个任意的意见：

以下是典型的 decisionMaker actor 调用代码，可以说明这一点：

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

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

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

这个片段 可能 会产生（取决于恢复的时间）以下的执行顺序：

opinion = .goodIdea                // <1>
// 暂停: await friend.tell(...) // <2>
opinion = .badIdea                 // | <4> (!)
// 暂停: await friend.tell(...) // | <5>
// 恢复: await friend.tell(...)  // <2>
return opinion                     // <3>
// 恢复: await friend.tell(...)  // <5>
return opinion                     // <6>

但它也 可能 导致 “naively expected” 的执行，即没有交织，这意味着问题只会间歇性地出现，就像并发代码中的许多竞赛条件。

在暂停点上有可能出现交织执行，这是要求每个暂停点在源代码中用 await 标记的主要原因，尽管 await 本身没有语义作用。这是一个提示，表明任何共享状态都可能在 await 中发生变化，所以应该避免在 await 中破坏不变性，或者依赖 “之前”的状态与”之后”的状态一致。

一般来说，避免跨 await 破坏不变性的最简单方法是将状态更新封装在同步 actor 函数中。实际上，actor 中的同步代码提供了一个临界区，而 await 中断了一个临界区。对于我们上面的例子，我们可以通过将 “optinion fomration” 与 “telling a friend your opinion” 分开来实现这个修改。事实上，告诉你的朋友你的观点可能会合理地导致你改变你的观点！

不可重入的 actor 的死锁

与可重入的 actor 函数相反的是”不可重入”的函数和 actor。这意味着当一个actor 正在处理一个传入的 actor 函数调用（消息）时，它将不会处理来自其邮箱的任何其他消息，直到它完成运行这个初始函数。本质上，整个 actor 都会被阻塞，直到该任务完成。

如果我们以上一节的例子为例，使用一个非重入 actor，它将正确执行，因为在 friend.tell 完成之前，不能给 actor 安排工作：

// 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
  }
}

然而，如果一个任务涉及到回调 actor，非重入就会导致死锁。例如，让我们进一步延伸这个例子，让我们的朋友试图说服我们改变一个坏主意：

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

对于非重入的 actor，thinkOfGoodIdea() 在这种实现下会成功，因为 tell 基本上什么都不做。然而，thinkOfBadIdea() 将陷入僵局，因为原来的决策者（称为 A）在对另一个决策者（称为 B）调用 tell 时被锁定。然后，B 试图说服 A，但该调用无法执行，因为 A 已经被锁定。因此，actor 自身进入死锁，无法进行下去。

这些讨论中使用的术语”死锁”是指 actor 异步地等待”彼此”或”自己的未来工作”。对于这个问题来说，线程阻塞不是必要条件。

理论上，一个完全不重入的模型在调用 self 上的异步函数时也会出现死锁。然而，由于这种调用可以静态地确定是在 self 上，它们会立即执行，因此不会阻塞。

可以用运行时工具来检测非重入 actor 的死锁，这些工具可以在死锁发生后检测循环调用图，就像在运行时检测数据结构中的引用循环一样。然而，这种死锁通常不能被静态地识别（例如，用编译器或静态分析），因为调用图需要整个程序的知识，并且会根据提供给程序的数据动态变化。

死锁的 actor 将永远作为不活跃的僵尸呆在那里。一些运行时为了解决这样的死锁问题，让每个 actor 的调用都有一个超时时间（分布式 actor 系统已经证实这种超时机制确实行之有效）。这意味着每个 await 都有可能 throw，而超时或死锁检测都必须始终被启用。我们认为这个代价太过昂贵，因为我们设想在绝大多数并发的 Swift 应用中都会使用 actor。这也会搅浑取消机制，取消机制是有意设计成明确和可合作的。因此，我们觉得自动取消死锁的方法并不符合 Swift 并发的方向。

不可重入的 actor 非必要的阻塞

想想看一个处理各种图片下载的 actor，并保存对已下载内容的缓存，以使后续访问更快：

// 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]
  }
}

这个 actor 在功能上是正确的，不管它是否是可重入的。然而，如果它是非重入的，它将逐个执行图片的下载：一旦一个客户端请求了一张图片，所有其他的客户端将被阻止开始任何请求 – 即使是那些会击中缓存或在不同的 URL 上请求图片的请求 – 直到第一个客户端将其图片完全下载和解码。

而使用可重入的 actor 时，多个客户端可以独立地获取图像，这样（比如）他们都可以处于下载和解码图像的不同阶段。actor 上部分任务的串行执行确保了缓存本身不会被破坏。在最坏的情况下，两个客户可能会同时要求获得相同的图像URL，其中会有一些多余的工作。

已有的实践

有一些现有的 actor 实现已经考虑了重入的概念：

• Erlang/Elixir（gen_server）展示了一个简单的 “loop/deadlock” 场景以及如何检测和修复它。
• Akka（Persistence persist/persistAsync)实际上是默认 非重入的 ，特定的 API 被设计为允许程序员在需要时 选择 重入。在链接的文档中，persistAsync 是 API 的可重入版本，它在实践中很少被使用。Akka 持久化和这个 API 已经被用来实现银行交易和流程管理，依靠 persist() 的非重入性作为杀手锏，使得实现简单易懂且 安全 。注意，Akka 是建立在 Scala 之上的，Scala 不提供 async/await。这意味着邮箱处理方法在本质上更具有同步性，与其在等待响应时阻塞 actor，不如将响应作为一个单独的消息接收来处理。
• Orleans（grains）默认也是非重入的，但围绕重入性提供了可拓展的配置。Grains 和特定的方法可以被标记为可重入，甚至还有一种动态机制，可以实现一个运行时的断言来确定一个调用是否可以交织执行。Orleans 也许最接近这里描述的 Swift 方法，因为它是建立在提供 async/await 的语言之上的（C#）。请注意，Orleans 有一个叫做调用链重入的功能，我们认为这是一个很有前途的潜在方向：我们在本提案后面的任务链重入一节中会介绍它。

Reentrancy 总结

本提案只提供了可重入的 actor。然而，未来方向小节里阐述了潜在的未来设计方向，可以增加可选的非重入性。

理由。默认情况下，重入可以消除死锁的可能性。此外，它还有助于确保 actor 在并发系统中能及时取得进展，并确保特定的 actor 不会在长期运行的异步操作（例如，下载文件）中出现不必要的阻塞。确保安全交织的机制，例如在执行突变时使用同步代码，并注意不破坏跨 await 调用的不变性，已经存在于该提案中。

Protocol conformances

所有的 actor 类型都默认遵循一个新的协议，Actor。

protocol Actor : AnyObject, Sendable { }

注意。Actor 协议的定义是故意留白的。Custom executor 提案将在 Actor 协议中引入实现要求。当没有明确提供时，这些要求将被实现隐含地合成，但可以明确地提供，以允许 actor 控制自己的串行执行。

Actor 协议可以用来编写适用于所有 actor 的通用操作，包括用新的操作扩展所有 actor 类型。与 actor 类型一样，在 Actor 协议上定义的实例属性、函数和下标（包括其扩展）是与 self actor 隔离的。例如：

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
}

其他类型的具体类型（类、枚举、结构等）都不能遵循 Actor 协议，因为它们不能定义被 actor 隔离的操作。

Actor 也可以遵循具有 async 要求的协议，因为所有的客户都已经不得不与这些实现要求进行异步交互，使得 actor 有能力保护它隔离的状态。比如说：

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
  }
}

Actor 不能被用来遵循具有同步要求的非 Actor 协议。然而，有一个关于控制 actor 隔离的单独提议，当它们能够以不引用任何 mutable actor 状态的方式实现时，允许这种遵循。

具体设计

Actors

Actor 类型可以用 actor 关键字来声明：

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

每个 actor 的实例都代表一个唯一的 actor。术语 “actor” 可以用来指代实例或类型；在必要时，人们可以使用 ”actor 实例” 或 “actor 类型 “来消除歧义。

Actor 类似于 Swift 中的其他具体名义类型（enum, struct 和 class）。Actor 类型可以有 static 和实例方法、属性和下标。它们像 stuct 和 class 一样有存储属性和初始化器。它们像 class 一样是引用类型，但不支持继承，因此没有（或不需要）诸如 required 和 convenience 初始化器、override 、或 class 成员、open 和 final 等功能。Actor 类型在行为上与其他类型的不同之处主要是由 actor isolation 的规则驱动的，如下所述。

默认情况下，actor 的实例方法、属性和下标有一个隔离的 self 参数。即使是通过扩展在 actor 上追加的方法也是如此，就像其他 Swift 类型一样。静态方法、属性和下标没有一个作为 actor 实例的 self 参数，所以它们不是与被 actor 隔离的。

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

Actor 隔离检查

程序中的任何给定的声明要么是被 actor 隔离的，要么是不被隔离的。如果一个函数（包括访问器）定义在一个 actor 类型上（包括 Self 符合 Actor 的协议，以及其扩展），那么它就是被 actor 隔离的。如果一个 mutable 的实例属性或实例下标是定义在一个 actor 类型上的，那么它就是被 actor 隔离的。不被 actor 隔离的声明被称为不被隔离的（non-isolated）。

Actor isolation 规则会在很多地方被检查，在这些地方，需要对两个不同的声明进行比较，以确定它们在一起的使用是否保持了 actor 的隔离。有几个这样的地方：

• 当一个声明的定义（例如，一个函数的主体）引用另一个声明时，例如，调用一个函数，访问一个属性，或执行一个下标。
• 当一个声明满足了一个协议要求时。

我们将详细地描述每种情况。

引用和 actor 的隔离

一个被 actor 隔离的非 async 声明只能从另一个与同一 actor 隔离的声明中被同步访问。对于同步访问一个被 actor 隔离的函数，该函数必须从另一个被 actor 隔离的函数中调用。对于同步访问一个被 actor 隔离的实例属性或实例下标，该实例本身必须是被 actor 隔离的。

一个被 actor 隔离的声明可以从任何声明中被异步访问，无论它是被隔离到另一个 actor 还是不被隔离。这样的访问是异步操作，因此必须用 await 来注释。从语义上讲，程序将切换 actor 来执行同步操作，之后再切换回调用者的 executor。

例如：

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(other.name)    // 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
  }
}

Protocol conformance

当某项声明（”witness”）满足某项协议要求（”requirement”）时，在以下情况下，witness 可以满足该协议要求：

• Requirement 是 async，或
• Requirement 和 witness 都是被 actor 隔离的。

一个 actor 可以满足异步的要求，因为对该要求的任何使用都是异步的，因此可以暂停，直到该 actor 可以执行它们。请注意，一个 actor 可以用一个同步的实现来满足一个异步的实现需求，在这种情况下，异步访问一个 actor 上的同步声明的正常规则是适用的。比如说：

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

只有当表达式是一个直接的参数，其对应的参数是 non-escaping 和 non-Sendable 时，才允许隔离函数的 partial applications。例如：

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

actor A {
  func f(_: Int) -> Double { ... }
  func g() -> Double { ... }
  
  func useAF(array: [Int]) {
    array.map(self.f)                     // okay
    detach(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
  }
}

这些限制来自于 actor 对闭包的 partial applications “desugaring” 后生效的隔离规则。上面两个错误的例子是由于在执行调用的闭包中，闭包将是不被隔离的，所以对被 actor 隔离的函数 g 的访问必须是异步的。下面是 partial application 的 “desugared” 形式：

extension A {
  func useAFDesugared(a: A, array: [Int]) {
    array.map { f($0) } )      // okay
    detach { 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

一个 keypath 不能涉及对被 actor 隔离声明的引用：

actor A {
  var storage: Int
}

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

理由。允许生成引用 actor isolation 的属性或下标的 keypath，将允许从 actor isolation 域之外访问 actor 的受保护状态。作为这一规则的替代方案，我们可以从 keypath 中移除 Sendable 的遵循，这样人们就可以形成指向被 actor 隔离状态的 keypath，但它们不能被共享。

inout 参数

被 actor 隔离的存储属性可以通过 inout 参数传递到同步函数中，但通过 inout 参数传递到异步函数中是不符合规定的。比如说：

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
  }
}

理由：这个限制可以防止违反独占性，在这种情况下，对被 actor 隔离的 balance 的修改是通过把它作为 inout 传递给一个调用而开始的，这个调用被暂停，然后在同一个 actor 上执行的另一个任务试图访问 balance。这样的访问将导致违反独占性，从而终止程序。虽然 inout 的限制对于内存安全来说是不需要的（因为错误会在运行时被检测到），但 actor 的默认重入性使得它很容易引入非确定性的独占性违规。因此，我们引入了这个限制，以消除这类问题，即竞赛会触发独占性的违规。

Actor 与 Objective-C 的交互

一个 actor 类型可以被声明为 @objc，它隐式地提供了对 NSObjectProtocol 的遵循：

@objc actor MyActor { ... }

Actor 的成员只有在 async 或不被 actor 隔离的情况下才能标注为 @objc。在 actor 的隔离域内的同步代码只能在 self 上调用（在 Swift 中）。Objective-C 并不了解 actor 的隔离，所以这些成员不允许暴露在 Objective-C 中。比如说：

@objc actor MyActor {
    @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
}

代码兼容性

这个建议主要是补充性的，不应该会破坏源代码的兼容性。引入 Actor 的 actor 上下文关键字是对解析器的改变，不会破坏现有的代码，其他的改变也是精心设计的，所以它们不会改变现有的代码。只有引入 actors 或 actor-isolation 属性的新代码会受到影响。

对于 ABI 稳定性的影响

这纯粹是对 ABI 的补充。Actor isolation 本身是一个静态概念，不是 ABI 的一部分。

对于 API 稳定性的影响

几乎所有 actor isolation 的改变都是破坏性的改变，因为 actor isolation 规则要求声明和其用户之间的一致性。

• 一个 class 不能变成一个 actor，反之亦然。
• 一个公共声明的 actor isolation 不能被改变。

未来方向

Non-reentrancy

我们可以引入一个 @reentrant 注解，它可以被添加到任何被 actor 隔离的函数、actor 或 actor 的扩展中，以描述它是如何重入的。该属性将有几种形式：

• @reentrant: 表示被注解的函数体中的每个潜在暂停点是可重入的。
• @reentrant(never): 表示被注解的函数体中的每个潜在暂停点都是不可重入的。

一个不可重入的潜在暂停点会阻止任何其他异步调用在 actor 上执行，直到它完成。请注意，直接在 self 上对非重进异步函数的异步调用不受这个检查的影响，所以一个 actor 可以异步调用自己而不产生死锁。

理由。允许直接调用 self 可以消除一系列明显的死锁，并且只需要与被 actor 隔离检查相同的静态信息，就可以同步访问被 actor 隔离的状态。

在一个不被隔离的函数、非 actor 类型或非 actor 类型的扩展上使用 @reentrant 注解是错误的。只有给定的声明中可以使用 @reentrant 注解。一个被 actor 隔离的非类型声明的可重入性是通过寻找一个合适的 @reentrant 属性来确定的。搜索的路径如下：

1. 声明本身。
2. 如果声明是一个扩展的非类型成员，则是该扩展。
3. 如果声明是一个类型（或其扩展）的非类型成员，则是类型定义。

如果没有合适的 @reentrant 注解，被 actor 隔离的声明就是可重入的。

下面有一个例子，说明如何在不同地方使用 @reentrant 注解：

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

@reentrant(never)
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

注解不是这里唯一可能的设计方向。在实现层面上，实际的阻塞将在每个异步调用点处理。我们可以引入一个不同形式的 await 来进行阻塞，而不是一个可能影响许多异步调用的注解，例如：

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

Task-chain reentrancy

关于可重入和不可重入 actor 的讨论都将重入视为一种二元选择，所有形式的重入都被认为是同样可能引入难以解释的数据竞赛。然而，常见的、通常很容易理解的 actor 之间的交互方式，它只是两个或多个 actor 之间的”对话”，以实现一些原始的请求。在同步代码中，让两个或多个不同的 class 以同步调用的方式相互回调是很常见的。例如，这里是 isEven 的一个愚蠢的实现，它在两个 class 之间使用了相互递归：

class OddOddySync {
  let evan: EvenEvanSync!

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

class EvenEvanSync {
  let oddy: OddOddySync!

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

这段代码依赖于这些 class 的两个方法在同一个调用堆栈中有效的”可重入”，因为其中一个会调用到另一个（反之亦然）作为计算的一部分。现在，以这个例子为例，用 actor 使其成为异步的：

@reentrant(never)
actor OddOddy {
  let evan: EvenEvan!

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

@reentrant(never)
actor EvenEvan {
  let oddy: OddOddy!

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

在 @reentrant(never) 下，这段代码会出现死锁，因为从 EvanEvan.isEven 到 OddOddy.isOdd 的调用将依赖于对 EvanEvan.isEven 的另一次调用，在原始调用完成之前，无法继续。我们需要使这些方法成为可重入的，以消除死锁。

随着 Swift 将结构化并发作为其并发功能的核心组件，我们可能会比直接禁止重入做得更好。在 Swift 中，每个异步操作都是 Task 的一部分，Task 封装了正在进行的一般计算，从这种任务中产生的每个异步操作都成为当前任务的一个子任务。因此，可以知道某个异步调用是否属于同一个任务层次，这大致相当于在同步代码中处于同一个调用栈。

我们可以引入一种新的重入，任务链重入，它允许代表给定任务或其任何子任务的重入调用。这既解决了我们在 deadlocks 一节中的 convinceOtherwise 例子中遇到的死锁，也解决了上面 isEven 例子中的相互递归，同时还能防止不相关任务的再入。因此，这种重入更接近于模仿同步代码，消除了许多死锁，而不需要允许无关的交织执行破坏 actor 的高层不变性。

我们目前没有把任务链重入性纳入到提案中有这几个原因：

• 基于任务的重入方法似乎还没有被大规模地尝试过。Orleans 记录了对调用链中的重入的支持，但实施相当有限，最终被删除。从 Orleans 的经验来看，很难评估问题是出在想法上还是具体的实现上。
• 我们还不知道这种方法在 actor 运行时中的有效实现方式。

如果我们能够解决上述问题，任务链重入可以通过重入属性的另一种参数，如 @reentrant(task)，引入到 actor 模型中，并可能提供最佳的默认值。

其它替代方案

Actor 继承

早期的草案和本提案的第一个版本允许 actor 继承。Actor 的继承遵循 class 的继承规则，尽管有特定的额外规则来维持 actor 的隔离：

• 一个 actor 不能继承于一个 class ，反之亦然。
• 一个 override 的声明不能比被 override 的声明的隔离等级高。

随后的审查讨论确定，actor 继承的概念成本超过了它的实用性，所以它已经从这个提案中删除。actor 继承在语言中采取的形式，在本提案的先前迭代和实施中已被充分理解，所以这一特性可以在以后重新引入。

跨 actor lets

这个提案允许从定义 actor 的同一 module 的任何地方同步访问 actor 实例上的 let 属性：

// in module BankActors
public actor BankAccount {
  public let accountNumber: Int
}

func print(account: BankAccount) {
  print(account.accountNumber) // okay: synchronous access to an actor's let property
}

在 module 之外的访问必须是异步的：

import BankActors

func otherPrint(account: BankAccount) async {
  print(account.accountNumber)         // error: cannot synchronously access immutable 'let' outside the actor's module
  print(await account.accountNumber)   // okay to asynchronously access
}

对 module 之外必须异步访问的要求，为库实现者提供了长期的自由度，使得 public 的 let 可以被重构为 var 的同时，不会破坏任何客户端。这与 Swift 的原则一致，即在不破坏客户端的情况下，最大限度地增加库实现者改变实现的自由。如果不要求其他 module 必须异步访问，上述的 otherPrint(account:) 函数将会被允许同步引用 accountNumber，BankActors 的作者随后将账号改为 var，就会破坏现有的客户端代码。

public actor BankAccount {
   public var accountNumber: Int     // version 2 makes this mutable, but would break clients if synchronous access to 'let's were allowed outside the module
 }

还有一些其他的语言功能也采取了同样的方法，即在一个 module 内减少模板和简化语言，然后当一个实体从 module 外使用时要求使用额外的语言功能。比如说：

• 访问控制默认为 internal，所以你可以在你的整个 module 中使用一个声明，但必须明确选择在你的 module 之外使用它（例如，通过 public）。换句话说，你可以忽略访问控制，直到你需要把某个东西 public 给其他 module 使用。
• struct 默认生成的构造器是 internal 的。你需要自己写一个 public 的构造器，以承诺允许该 struct 被初始化为一组确切的参数。
• 当父类在同一个 module 中时，默认允许从 class 中继承。要继承一个定义在不同 module 中的父类，该父类必须被明确标记为 open。你可以忽略 open，直到你想向 module 外的用户保证这种能力。
• 当被 override 的声明在同一个 module 中时，默认允许覆盖一个 class 中的声明。要从不同 module 的声明中覆盖，该覆盖的声明必须明确标记为 open。

SE-0313 “改进对 actor 隔离的控制“提供了一种显式的方式，让客户通过 nonisolated 关键字同步访问不可变的 actor 状态的自由，例如：

// in module BankActors
public actor BankAccount {
  public nonisolated let accountNumber: Int  // can be accessed synchronously from any module due to the explicit 'nonisolated'
}

这个提案最初通过的版本要求所有对不可变 actor 存储属性的访问都是异步的，并将任何同步的访问留给 SE-0313 中所阐述的显式 nonisolated 注解。然而，尝试使用该模型的过程表明，它有很多问题，影响了该模型的上手难度：

• 开发人员在编写 actor 代码时，几乎会立即需要使用 nonisolated。这违背了 Swift 试图让高级功能遵循的渐进式披露原则。除了 nonisolated let 之外，nonisolated 的使用相当少。
• 不可变的状态是编写安全并发代码的一个关键工具。Sendable 类型的 let 在概念上是安全的，可以从并发代码中引用，并在其他情况下工作（例如，局部变量）。使一些不可变的状态成为并发安全的，而其他状态则不是，这就使数据安全的并发编程的故事变得复杂。下面是一个围绕 @Sendable 的现有限制的例子，这些限制是在 SE-0302 中定义的：

  func test() { let total = 100 var counter = 0 asyncDetached { print(total) // okay to reference immutable state print(counter) // error, cannot reference a `var` from a @Sendable closure } counter += 1 }

通过允许在 module 内同步访问 actor 的 let 属性，我们为 actor 隔离提供了一个更平滑的学习曲线，并接纳（而不是颠覆）长期以来普遍存在的想法，即不可变的数据对并发是安全的，同时仍然解决了第二次审查中提出的担忧，即对 actor let 的无限制的同步访问隐含了一个库作者对该状态永不变的承诺。它遵循 Swift 语言中现有的先例，使 module 内的交互比跨 module 的交互更简单。

Revision history

• Changes in the post-review amendment to the proposal:
  • Cross-after references to instance let properties from a different module must be asynchronous; within the same module they will be synchronous.
• Changes in the final accepted version of the proposal:
  • Cross-actor references to instance let properties must be asynchronous.
• Changes in the second reviewed proposal:
  • Escaping closures can now be actor-isolated; only @Sendable prevents isolation.
  • Removed actor inheritance. It can be considered at some future point.
  • Added “cross-actor lets” to Alternatives Considered. While there is no change to the proposed direction, the issue is explained here for further discussion.
  • Replaced Task.runDetached with detach to match updates to the Structured Concurrency proposal.
• Changes in the seventh pitch:
  • Removed isolated parameters and nonisolated from this proposal. They’ll come in a follow-up proposal on controlling actor isolation.
• 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

原文链接：SE-0300 Continuations for interfacing async tasks with synchronous code

• Proposal: SE-0300
• Authors: John McCall, Joe Groff, Doug Gregor, Konrad Malawski
• Review Manager: Ben Cohen
• Status: Implemented
• Previous Revisions: 1, 2

简介

异步 Swift代 码需要能够与现有的同步代码一起工作，这些代码使用回调和 delegate 等方式来响应事件。异步任务可以在 continuations 上暂停自己，然后同步代码可以捕获并调用它来恢复任务以响应事件。

Swift-evolution thread:

• Structured concurrency
• Continuations for interfacing async tasks with synchronous code

动机

Swift 的 API 经常会通过回调的方式提供异步执行的功能。这种情况可能是因为代码本身是在引入 async/await 之前编写的，或者（更有趣的是，从长远来看）是因为它与其它一些（主要是）事件驱动的系统联系在一起。在这种情况下，人们可能希望向客户端提供一个异步接口，同时在内部使用回调。在这些情况下，调用异步任务需要能够暂停自己，同时提供一个机制让事件驱动的同步系统在响应事件时恢复它。

解决方案

本提案将提供 API 来获取当前异步任务的 continuation。获取任务的 continuation 会暂停任务，并产生一个值，同步的代码可以使用 handle 来恢复任务。给定一个基于 completionHandler 的 API，例如：

func beginOperation(completion: (OperationResult) -> Void)

我们可以把它变成一个 async 接口，先将当前的任务暂停，然后把它的 continuation 传入闭包中用来恢复任务，把传入回调的参数作为 async 函数的返回值：

func operation() async -> OperationResult {
  // 暂停当前任务，立即执行这个闭包，并且将它的 contunation 传进去
  return await withUnsafeContinuation { continuation in
    // 执行基于 callback 的同步 API
    beginOperation(completion: { result in
      // 当回调执行时恢复 contiuation
      continuation.resume(returning: result)
    }) 
  }
}

具体设计

原始的 unsafe continuations

本提案提供了两个函数，withUnsafeContinuation 和 withUnsafeThrowingContinuation，允许用户在异步代码内部使用基于回调的 API。这两个函数都需要传入一个 operation 闭包，它通常会在基于回调的 API 里调用。闭包里接收一个必须由回调恢复的 continuation 实例，用于提供结果值或（在 throw 的版本中）抛出错误，当异步任务恢复时，成为 withUnsafeContinuation 调用的结果：

struct UnsafeContinuation<T, E: Error> {
  func resume(returning: T)
  func resume(throwing: E)
  func resume(with result: Result<T, E>)
}

extension UnsafeContinuation where T == Void {
  func resume() { resume(returning: ()) }
}

extension UnsafeContinuation where E == Error {
  // 允许 Result 版本使用更严格的 Error 类型
  func resume<ResultError: Error>(with result: Result<T, ResultError>)
}

func withUnsafeContinuation<T>(
    _ operation: (UnsafeContinuation<T, Never>) -> ()
) async -> T

func withUnsafeThrowingContinuation<T>(
    _ operation: (UnsafeContinuation<T, Error>) throws -> ()
) async throws -> T

withUnsafe*Continuation 将在任务的当前上下文中立即执行它的 operation 参数，传入一个可用于恢复任务的 continuation 值。operation 函数必须安排在未来的某个时刻恢复 continuation；在 operation 函数返回后，任务就会被暂停。然后，必须通过调用 continuation 任意一个 resume 方法使任务脱离暂停状态。注意，resume 在将任务从暂停状态过渡出来后，会立即将控制权返回给调用者；任务本身实际上并不会恢复执行，而是等到它的执行者再次调度它。当任务恢复执行时，resume(returning:) 的参数会成为 withUnsafe*Continuation 的返回值。resume(throwing:) 可以通过传入给定的 Error 使任务恢复。为了方便起见，可以传入一个 Result，resume(with:) 会根据 Result 的状态，通过正常返回或抛出错误来恢复任务。如果 operation 在返回前引发了一个未捕获的错误，就会跟调用了 resume(throwing:) 一样。

如果 withUnsafe*Continuation 的返回类型是 Void，那么在调用 resume(returning:) 时必须传入 ()。这样做会产生一些丑陋的代码，所以 Unsafe*Continuation<Void> 有一个额外的方法 resume()，使调用代码更容易阅读。

在调用 withUnsafeContinuation 后，每个分支上都必须调用一次且仅一次 resume 方法。Unsafe*Continuation 是一个不安全的接口，所以同一个 continuation 多次调用 resume 方法属于未定义的行为。在任务被恢复之前，它会一直处于暂停状态；如果 continuation 被释放掉了，并且从未被恢复，那么任务将一直处于暂停状态，直到进程结束，它所拥有的任何资源都会泄漏。我们可以提供一层封装捕获这些错误的使用，本提案也打算引入这样的一个 Wrapper，下面将详细讨论。

例如，使用 Unsafe*Continuation API，可以封装这样的函数（这里为了展示 continuation API 的灵活性而故意弄得很复杂）：

func buyVegetables(
  shoppingList: [String],
  // a) if all veggies were in store, this is invoked *exactly-once*
  onGotAllVegetables: ([Vegetable]) -> (),

  // b) if not all veggies were in store, invoked one by one *one or more times*
  onGotVegetable: (Vegetable) -> (),
  // b) if at least one onGotVegetable was called *exactly-once*
  //    this is invoked once no more veggies will be emitted
  onNoMoreVegetables: () -> (),
  
  // c) if no veggies _at all_ were available, this is invoked *exactly once*
  onNoVegetablesInStore: (Error) -> ()
)
// returns 1 or more vegetables or throws an error
func buyVegetables(shoppingList: [String]) async throws -> [Vegetable] {
  try await withUnsafeThrowingContinuation { continuation in
    var veggies: [Vegetable] = []

    buyVegetables(
      shoppingList: shoppingList,
      onGotAllVegetables: { veggies in continuation.resume(returning: veggies) },
      onGotVegetable: { v in veggies.append(v) },
      onNoMoreVegetables: { continuation.resume(returning: veggies) },
      onNoVegetablesInStore: { error in continuation.resume(throwing: error) },
    )
  }
}

let veggies = try await buyVegetables(shoppingList: ["onion", "bell pepper"])

由于在 buyVegetables 函数的复杂回调里正确地对 continuation resume 进行了调用，我们能够为这个函数提供一个更好的重载，让异步代码以更自然的方式与这个函数交互。

Checked continuations

Unsafe*Continuation 为同步和异步代码的接口提供了一个轻量的机制，但它很容易用错，并且会以危险的方式破坏进程状态。为了提供额外的安全性和指导（在开发同步和异步代码交互的接口时），本提案还将提供一个 Wrapper，用于检查对 continuation 的非法使用：

struct CheckedContinuation<T, E: Error> {
  func resume(returning: T)
  func resume(throwing: E)
  func resume(with result: Result<T, E>)
}

extension CheckedContinuation where T == Void {
  func resume()
}

extension CheckedContinuation where E == Error {
  // Allow covariant use of a `Result` with a stricter error type than
  // the continuation:
  func resume<ResultError: Error>(with result: Result<T, ResultError>)
}

func withCheckedContinuation<T>(
    _ operation: (CheckedContinuation<T, Never>) -> ()
) async -> T

func withCheckedThrowingContinuation<T>(
  _ operation: (CheckedContinuation<T, Error>) throws -> ()
) async throws -> T

这里的 API 特意与 Unsafe 的 API 保持一致，因此代码可以很容易地在 checked 和 unsafe 的版本之间切换。例如，上面的 buyVegetables 例子只需将 withUnsafeThrowingContinuation 的调用变成 withCheckedThrowingContinuation 的调用，就可以提供运行时的检查：

// returns 1 or more vegetables or throws an error
func buyVegetables(shoppingList: [String]) async throws -> [Vegetable] {
  try await withCheckedThrowingContinuation { continuation in
    var veggies: [Vegetable] = []

    buyVegetables(
      shoppingList: shoppingList,
      onGotAllVegetables: { veggies in continuation.resume(returning: veggies) },
      onGotVegetable: { v in veggies.append(v) },
      onNoMoreVegetables: { continuation.resume(returning: veggies) },
      onNoVegetablesInStore: { error in continuation.resume(throwing: error) },
    )
  }
}

CheckedContinuation 不会导致未定义的行为，相反，如果程序试图多次 resume continuation 的话，CheckedContinuation 就会捕获到这种情况并且触发 trap。如果在没有恢复任务的情况下释放了 continuation，这使任务停留在它的暂停状态，泄露它所拥有的任何资源，并且 CheckedContinuation 会打印一个警告。无论程序采用了哪种优化级别，这些检查都会执行。

更多例子

Continuation 也可以用来跟（比回调）更复杂的事件驱动接口对接。只要整个过程都符合要求（continuation 只被恢复一次），那么在哪里恢复 continuation 就没有其它限制。例如，一个 Operation 可以在操作完成时触发 continuation 的恢复：

class MyOperation: Operation {
  let continuation: UnsafeContinuation<OperationResult, Never>
  var result: OperationResult?

  init(continuation: UnsafeContinuation<OperationResult, Never>) {
    self.continuation = continuation
  }

  /* rest of operation populates `result`... */

  override func finish() {
    continuation.resume(returning: result!)
  }
}

func doOperation() async -> OperationResult {
  return await withUnsafeContinuation { continuation in
    MyOperation(continuation: continuation).start()
  }
}

使用结构化并发提案中的 API，可以将一个 URLSession 包裹在一个任务中，让任务的取消来控制 session 的取消，并使用 continuation 来响应网络请求接收的数据和抛出的错误：

func download(url: URL) async throws -> Data? {
  var urlSessionTask: URLSessionTask?

  return try Task.withCancellationHandler {
    urlSessionTask?.cancel()
  } operation: {
    let result: Data? = try await withUnsafeThrowingContinuation { continuation in
      urlSessionTask = URLSession.shared.dataTask(with: url) { data, _, error in
        if case (let cancelled as NSURLErrorCancelled)? = error {
          continuation.resume(returning: nil)
        } else if let error = error {
          continuation.resume(throwing: error)
        } else {
          continuation.resume(returning: data)
        }
      }
      urlSessionTask?.resume()
    }
    if let result = result {
      return result
    } else {
      Task.cancel()
      return nil
    }
  }
}

围绕基于回调的 API 的 Wrapper 也可以跟随其父级/当前任务的取消，如下所示。

func fetch(items: Int) async throws -> [Items] {
  let worker = ... 
  return try Task.withCancellationHandler(
    handler: { worker?.cancel() }
  ) { 
    return try await withUnsafeThrowingContinuation { c in 
      worker.work(
        onNext: { value in c.resume(returning: value) },
        onCancelled: { value in c.resume(throwing: CancellationError()) },
      )
    } 
  }
}

如果允许任务拥有实例（这是在结构化并发提案里讨论的内容），那么也可以获得调用 fetch(items:) 函数的任务，并在 withUnsafeThrowingContinuation 内部认为需要时，调用它的 isCanceled。

其它方案

命名缩短为 Continuation（而不是 CheckedContinuation）

我们可以将 CheckedContinuation 定位为做同步/异步接口”默认”的 API，把 Checked 这个词从名字中去掉。这符合 Swift 的理念，首选安全的接口，而不安全的接口是性能成为首要考虑因素时才会选择性地使用。不过，这里有几个理由让我们很犹豫：

• 虽然错误使用 CheckedContinuation 的后果没有 UnsafeContinuation 那么严重，但它仍然只是尽最大努力检查一些常见的错误模式，并不能掩盖掉错误使用 continuation 的后果：释放一个 continuation 而不恢复它仍然会泄露未恢复的任务，而试图多次恢复一个 continuation 仍然会导致通过 continuation 传递的信息丢失。如果 with*Continuation 的操作错误使用 continuation，仍然是一个严重的程序逻辑错误； CheckedContinuation 只能使错误变得更加明显。
• 如果我们在未来的某个时候有了 move-only 类型，我们想引入一个静态的只恢复 exactly-once 的 continuation 类型，那么现在命名一个类型 Continuation 会占用掉这个”好”名字。

不暴露 UnsafeContinuation 接口

同样的，我们也可以得出另一个论点，即 UnsafeContinuation 根本不应该暴露给上层用户，因为用户总是会使用 Checked 的版本。但我们认为，在与性能敏感的 API 交互时，一旦用户验证了他们调用这些 API 的方式是正确的，避免掉 checked 的成本就是有价值的。

让 CheckedContinuation 在错误使用时全部触发 trap, 或者全部 log 出来

CheckedContinuation 的目的是当程序试图多次恢复同一个 continuation 时捕获这种情况，但如果一个 continuation 被释放而没有得到恢复，则只 log 一个警告。我们认为这是对不同情况的正确权衡，原因如下：

• 对于 UnsafeContinuation，多次恢复会破坏进程，使其处于未定义状态。通过在任务多次恢复时触发 trap，CheckedContinuation 就会将未定义的行为变成了定义良好的 trap。这类似于标准库中其它的 checked/unchecked 配对，例如 ! 与 Optional 的 unsafelyUnwrapped。
• 相比之下，如果没有用 UnsafeContinuation 来恢复 continuation，除了泄露暂停的任务的资源之外，并不会破坏任务，程序的其它部分也可以继续正常执行。此外，目前我们能检测和报告这种泄漏的唯一方法是在其实现中使用类的 deinit。由于 ARC 优化的 refcounting 变化，这样 deinit 执行的准确时机是完全无法预测的。如果把 deinit 做成 trap，那么这个 trap 是否被执行以及何时执行可能会随着优化等级的变化而变化，我们认为这不会带来很好的体验。

让 *Continuation 提供更多 Task API，或者允许 continuation 恢复 Handle

完整的 Task 和 Handle API 为 Handle 的持有者提供了对任务状态的额外控制，特别是查询和设置取消状态，以及等待任务最终结果的能力，大家可能会问，为什么 *Continuation 类型没有这些功能？Continuation 与 Handle 的作用有很大的不同，Handle 代表和控制任务的整个生命周期，而 continuation 只代表任务生命期中的一个暂停点。此外，*Continuation API 的设计主要是为了与 Swift 结构化并发模型之外的代码进行对接，我们认为任务之间的交互最好还是尽量在这个模型里处理。

注意，*Continuation 其实也不需要自己去直接提供任何任务的 API。例如，如果有人想让一个任务在响应回调时自行取消，他们可以通过控制 continuation 的 resume 类型来实现（例如一个 Optional 的 nil）：

let callbackResult: Result? = await withUnsafeContinuation { c in
  someCallbackBasedAPI(
    completion: { c.resume($0) },
    cancellation: { c.resume(nil) })
}

if let result = callbackResult {
  process(result)
} else {
  cancel()
}

提供 API 立刻恢复任务，避免队列跳转

有些 API 除了接收一个 completionHandler 或 delegate，还允许客户端控制 completionHandler 或 delegate 的方法调用的位置；例如，Apple 平台上的一些 API 接收一个参数，作为 completionHandler 应该被使用的 DispatchQueue。在这些情况下，如果原始 API 能够直接在 DispatchQueue（或其它任何调度机制，如 Thread 或 Runloop）上恢复任务，那将是最理想的。为了实现这一点，我们可以提供一个 with*Continuation 的变体，除了提供一个 continuation 之外，还提供任务期望被恢复的 DispatchQueue。*Continuation 类型也可以提供一套 unsafeResumeImmediately 的 API，它将立即在当前线程上恢复任务的执行。这样就可以实现下面的功能：

// Given an API that takes a queue and completion handler:
func doThingAsynchronously(queue: DispatchQueue, completion: (ResultType) -> Void)

// We could wrap it in a Swift async function like:
func doThing() async -> ResultType {
  await withUnsafeContinuationAndCurrentDispatchQueue { c, queue in
    // Schedule to resume on the right queue, if we know it
    doThingAsynchronously(queue: queue) {
      c.unsafeResumeImmediately(returning: $0)
    }
  }
}

然而，这样的 API 必须非常谨慎地使用；程序员必须保证 unsafeResumeImmediately 在正确的上下文中被调用，并且在任意时间内，从调用者手中接管当前线程的行为必须保证是安全的。如果在错误的上下文中恢复任务，就会破坏代码逻辑以及编译器和运行时的假设，这将导致难以诊断的奇妙 bug。如果 continuation-based adapter 的”队列跳转”在实践中被证实是一个性能问题，我们可以将其作为核心提案的补充进行研究。

修订历史

Third revision:

• Replaced separate *Continuation<T> and *ThrowingContinuation<T> types with a single Continuation<T, E: Error> type parameterized on the error type.
• Added a convenience resume() equivalent to resume(returning: ()) for continuations with a Void return type.
• Changed with*ThrowingContinuation to take an operation block that may throw, and to immediately resume the task throwing the error if an uncaught error propagates from the operation.

Second revision:

• Clarified the execution behavior of with*Continuation and *Continuation.resume, namely that with*Continuation immediately executes its operation argument in the current context before suspending the task, and that resume immediately returns to its caller after un-suspending the task, leaving the task to be scheduled by its executor.
• Removed an unnecessary invariant on when resume must be invoked; it is valid to invoke it exactly once at any point after the with*Continuation operation has started executing; it does not need to run exactly when the operation returns.
• Added “future direction” discussion of a potential more advanced API that could allow continuations to directly resume their task when the correct dispatch queue to do so is known.
• Added resume() on Void-returning Continuation types.

原文链接：SE-0298 Async/Await: Sequences

• Proposal: SE-0298
• Authors: Tony Parker, Philippe Hausler
• Review Manager: Doug Gregor
• Status: Implemented (Swift 5.5)
• Implementation: apple/swift#35224
• Decision Notes: Rationale
• Revision: Based on forum discussion

简介

Swift 的 async/await 特性提供了一种直观的、内建的方式来编写和使用在未来某个时间点返回一个值的函数。我们建议在这个特性的基础上，添加一种直观的、内置的方式来编写和使用在一段时间内返回多个值的函数。

本提案由以下三个部分组成：

1. 增加一个表示异步序列的协议到标准库里
2. 在异步序列上使用 for...in 语法的编译器支持
3. 对异步序列进行操作的通用函数的标准库实现

动机

我们希望在异步序列上的遍历能够像在同步序列上的遍历一样简单。一个例子是遍历文件的每一行，像这样：

for try await line in myFile.lines() {
  // Do something with each line
}

使用 Swift 开发者已经熟悉的 for...in 语法可以降低异步 API 的入门门槛。因此，保持与其他 Swift 类型和概念的一致性是我们最重要的目标之一。在这个循环中使用 await 关键字的可以把它与同步序列区分开来。

for/in 语法

为了实现 for in 语法，我们必须将 func lines() 的返回类型定义为可迭代的某些东西（编译器能理解的）。目前我们有 Sequence 协议。可以试着在这里使用它：

extension URL {
  struct Lines: Sequence { /* ... */ }
  func lines() async -> Lines
}

不幸的是，这个函数实际上做的是等待，直到所有行都可用时才返回。在这种情况下，我们真正想要的是 await 每一行。虽然可以想象对 lines 进行修改，使其行为不同（例如，让结果的类型变成引用语义），但最好是定义一个新的协议，使这种迭代行为尽可能简单。

extension URL {
  struct Lines: AsyncSequence { /* ... */ }
  func lines() async -> Lines
}

AsyncSequence 通过在其关联的迭代器类型上定义一个异步 next() 函数，允许对每个元素而不是整个结果进行等待。

新增的 AsyncSequence 函数

再进一步，让我们想象一下，在更多的地方使用我们新的 lines 函数会是什么样子。也许我们想处理每一行，直到其中一行的长度大于一定的长度。

let longLine: String?
do {
  for try await line in myFile.lines() {
    if line.count > 80 {
      longLine = line
      break
    }
  }
} catch {
  longLine = nil // file didn't exist
}

又或者，我们实际上是想在开始处理之前读取文件中的所有行：

var allLines: [String] = []
do {
  for try await line in myFile.lines() {
    allLines.append(line)
  }
} catch {
  allLines = []
}

上面的代码没有错，开发者一定可以写出来。然而，对于普通的操作来说，它确实看起来会多很多模版代码。解决这个问题其中一个方式是在 URL 中增加更多的函数：

extension URL {
  struct Lines : AsyncSequence { }

  func lines() -> Lines
  func firstLongLine() async throws -> String?
  func collectLines() async throws -> [String]
}

不过，可以想象我们可能会在其他地方进行类似的操作。因此，我们认为最好是将这些函数作为 AsyncSequence 本身的扩展，用一种更泛用的方式 – 就像 Sequence 一样。

解决方案

标准库将会添加以下两个协议：

public protocol AsyncSequence {
  associatedtype AsyncIterator: AsyncIteratorProtocol where AsyncIterator.Element == Element
  associatedtype Element
  __consuming func makeAsyncIterator() -> AsyncIterator
}

public protocol AsyncIteratorProtocol {
  associatedtype Element
  mutating func next() async throws -> Element?
}

编译器将会自动生成代码，让我们可以在符合 AsyncSequence 的任何类型上使用 for in 循环。标准库还将扩展协议以提供熟悉的通用算法。下面是一个例子，它实际上并没有在其 next 中调用 async 函数，但是展示了基本的概念：

struct Counter : AsyncSequence {
  let howHigh: Int

  struct AsyncIterator : AsyncIteratorProtocol {
    let howHigh: Int
    var current = 1
    mutating func next() async -> Int? {
      // We could use the `Task` API to check for cancellation here and return early.
      guard current <= howHigh else {
        return nil
      }

      let result = current
      current += 1
      return result
    }
  }

  func makeAsyncIterator() -> AsyncIterator {
    return AsyncIterator(howHigh: howHigh)
  }
}

在调用方会这么使用 counter：

for await i in Counter(howHigh: 3) {
  print(i)
}

/* 
Prints the following, and finishes the loop:
1
2
3
*/


for await i in Counter(howHigh: 3) {
  print(i)
  if i == 2 { break }
}
/*
Prints the following:
1
2
*/

具体设计

回到我们之前的例子：

for try await line in myFile.lines() {
  // Do something with each line
}

编译器将生成类似于下面的代码：

var it = myFile.lines().makeAsyncIterator()
while let line = try await it.next() {
  // Do something with each line
}

所有关于错误处理的常规规则都适用。例如，这个迭代必须被 do/catch 包围，或者在 throws 函数中处理错误。所有关于 await 的常规规则也适用。例如，这个迭代必须在一个允许调用 await 的上下文中，就像一个 async 函数一样。

Cancellation

AsyncIteratorProtocol类型应该使用 structured concurrency 的一部分，Swift 的 Task API 提供的”取消”功能。正如那里面所描述的，迭代器可以选择如何响应“取消”。最常见的行为是抛出 CancellationError 或者让迭代器返回 nil。

如果一个 AsyncIteratorProtocol 类型在取消时要清理资源，它可以在这两个地方进行：

1. 使用 Task API 检查是否取消之后。
2. 在其 deinit 中（如果它是 class 类型）。

Rethrows

该提案将利用另一项提案，在协议中增加专门的 rethrows 一致性，该提案已在这里提出。根据该提案对 rethrows 的修改，当迭代一个本身不抛出的 AsyncSequence 时，将不需要使用 try。

而 await 总是需要有的，因为协议的定义里它总是异步的。

结束迭代

在 AsyncIteratorProtocol 类型的 next() 方法返回 nil 或抛出错误之后，后续所有对 next() 调用都必须返回 nil。 与 IteratorProtocol 类型的行为保持一致，这很重要，因为调用迭代器的 next() 方法是确定迭代是否完成的唯一方法。

AsyncSequence 函数

标准的 AsyncSequence 协议的存在使我们能够为任何符合该协议的类型编写通用算法。有两类函数：返回一个单一值的函数（因此被标记为 async），和返回一个新的 AsyncSequence 的函数（本身没有标记为 async）。

返回单个值的函数特别有趣，因为它们可以将一个循环改为一行 await，增加了可用性。例如 first、contains、min、max、reduce 等。返回一个新的 AsyncSequence 的函数有 filter、map、compactMap。

将 AsyncSequence 转换为一个值

将 for 循环缩减为一次调用的算法可以提高代码的可读性。它们消除了设置和迭代循环所需的模板。

例如，下面是 contains 函数：

extension AsyncSequence where Element : Equatable {
  public func contains(_ value: Element) async rethrows -> Bool
}

通过这个扩展，我们前面的”超过 80 个字符的第一行”的例子就可以简化成这样：

let first = try? await myFile.lines().first(where: { $0.count > 80 })

或者，如果该序列应该被异步处理并且在之后才会使用：

async let first = myFile.lines().first(where: { $0.count > 80 })

// later

warnAboutLongLine(try? await first)

AsyncSequence 将增加以下功能：

将 AsyncSequence 转换为另一个 AsyncSequence

这些关于 AsyncSequence 的函数会返回一个结果，这个结果本身就是一个 AsyncSequence。由于 AsyncSequence 的异步性质，其行为在许多方面与标准库中现有的 Lazy 类型相似。调用这些函数并不急于 await 序列中的下一个值，而是由调用者决定何时开始该工作，只需在准备好时开始迭代即可。

举个例子，让我们看看 map：

extension AsyncSequence {
  public func map<Transformed>(
    _ transform: @escaping (Element) async throws -> Transformed
  ) -> AsyncMapSequence<Self, Transformed>
}

public struct AsyncMapSequence<Upstream: AsyncSequence, Transformed>: AsyncSequence {
  public let upstream: Upstream
  public let transform: (Upstream.Element) async throws -> Transformed
  public struct Iterator : AsyncIterator { 
    public mutating func next() async rethrows -> Transformed?
  }
}

对于这种函数，我们首先定义一个符合 AsyncSequence 协议的类型，这个名字是仿照现有的标准库 Sequence 类型，如 LazyDropWhileCollection 和 LazyMapSequence。这个名字是仿照现有的标准库 Sequence 类型，如 LazyDropWhileCollection 和 LazyMapSequence。然后，我们在 AsyncSequence 上的扩展中添加一个函数，该函数创建新的类型（使用 self 作为 upstream）并返回。

未来的改进方向

以下是我们认为重要且值得在今后的提案中讨论的话题：

补充更多 AsyncSequence 函数

这个提案的目标是与最相关的 Sequence 函数保持一致。可能还有其他值得在今后的提案中添加的功能。

使用时间作为参数的 API 必须与结构化并发提案中的 Executor 一起进行讨论。

我们希望有一个 first 属性，但目前 Swift 里的属性不能标记为 async 或 throws。目前正在讨论在语言中增加一种能力，以允许对属性产生影响。如果这些功能成为了 Swift 的一部分，那么我们应该在 AsyncSequence 中添加一个 first 属性。

AsyncSequence Builder

在标准库中，我们不仅有 Sequence 和 Collection 协议，还有采用这些协议的具体类型（例如 Array）。我们需要为 AsyncSequence 提供一个类似的 API，以便在需要的时候很容易地构造一个具体的实例，而不需要声明一个新的类型和增加协议的一致性。

代码兼容性

这个新功能将与现有的 Swift 代码兼容。

对于 ABI 稳定性的影响

这里的修改是对 ABI 的补充性修改。

对于 API 兼容性的影响

这里的修改是对 API 的补充性修改。

其它方案

显式 Cancellation

该提案的早期版本包括一个明确的 cancel 功能。出于以下原因，我们决定将它删除掉：

1. 减少实现 AsyncIteratorProtocol 的要求，使其更容易使用和理解。关于什么时候调用 cancel 的规则，虽然简单明了，但对于 Swift 开发者来说，还是要多学一样东西。
2. 结构化并发提案中已经包含了一个对 AsyncSequence 取消的明确定义。我们应该把异步代码的取消行为整体视为一个概念。

异步 Cancellation

如果我们使用显式取消，迭代器的 cancel() 函数可以标记为 async。然而，这意味着在离开 for/in 循环时进行的隐式取消将需要一个隐式的 await – 我们认为这对开发者来说可能太过隐蔽。大多数的取消行为会像设置一个标志以便稍后检查一样简单，所以我们让它作为一个同步函数存在，鼓励采用者让取消行为可以快速执行并且不会阻塞。

Opaque 类型

每个 AsyncSequence 到 AsyncSequence 的算法都会定义自己的具体类型。我们可以尝试将这些细节隐藏在一个通用的类型擦除器后面。我们相信让类型暴露出来会给我们（和编译器）更多的优化机会。未来的一个潜在的巨大改进是让语言支持 some AsyncSequence where Element=... 风格的语法，允许在 API 里隐藏具体的 AsyncSequence 类型。

复用 Sequence

如果语言支持 reasync 概念，那么 AsyncSequence 和 Sequence API 合并起来似乎是合理的。然而，我们认为，将其视为两种不同的类型仍然是有价值的。异步代码中增加了时间维度的复杂性，这意味着一些函数需要更多的配置选项或更复杂的实现。一些在异步序列上有用的算法在同步序列上是没有意义的。在这些情况下，我们最好不要让同步集合类型的 API 复杂化。

命名

具体的 AsyncSequence 类型的名称被设计为镜像现有的标准库 API，如 LazyMapSequence。另一种选择是用一个空的枚举或其他命名机制引入一个新的模式。

我们考虑过 AsyncGenerator，但希望保留 Generator 这个名称给后续的功能实用。Stream 是Foundation 中的一个类型，因此我们没有在这里重复使用，避免混淆。

await in

我们考虑过一个更短的 await...in 的语法。然而，由于这里的行为从根本上说是一个循环，我们认为必须使用现有的 for 关键字作为对代码读者的强烈信号。虽然有很多关键字，但它们每一个关键字对代码的读者来说都有目的和意义。

添加 API 到 Iterator 里（而不是 Sequence）

我们讨论了将基本 API(map、reduce 等)应用于 AsyncIteratorProtocol 而不是 AsyncSequence。在 Sequence API 中一直存在着一个长期的（虽然是故意的）歧义 – 它到底应该是一次还是多次循环？这个新的迭代器和序列提供了一个更具体地定义这个问题的机会。

虽然很想用这个新的API来纠正过去的错误，但我们认为，与现有 Swift 概念保持一致的原则性目标更为重要。

例如，for...in 不能用于 IteratorProtocol – 只能用于 Sequence。如果我们选择让 AsyncIteratorProtocol 使用这里描述的 for...in，那我们就只能选择在 AsyncIteratorProtocol 和 IteratorProtocol 之间引入不一致的行为，或者放弃熟悉的 for...in 语法。即使我们决定在 IteratorProtocol 中加入 for...in，它仍然是不一致的，因为我们需要在现有的 Sequence 上留下 for...in 语法。

倾向于保持一致性的另一个原因是，实现 AsyncSequence 对于任何知道如何实现 Sequence 的人来说都会感到熟悉。

我们希望在 API 中广泛采用该协议，通常情况下，API 会使用 Notification、delegate 或者回调。在大部分这样的情况下，我们觉得 API 应该返回 “工厂类型”（一个 AsyncSequence），以便它可以再次迭代。调用者仍然需要知道执行该操作的任何基本成本，就像今天任何 Sequence 的迭代一样。

原文链接：SE-0297 Concurrency Interoperability with Objective-C

• Proposal: SE-0297
• Author: Doug Gregor
• Review Manager: Chris Lattner
• Status: Implemented (Swift 5.5)
• Acceptance Post
• Implementation: Partially available in recent main snapshots behind the flag -Xfrontend -enable-experimental-concurrency

简介

Swift 的并发功能包括了异步函数和 actor。虽然 Objective-C 没有相应的语言特性，但异步 API 在 Objective-C 中很常见，通过使用 completion-handler 手动实现。本提案提供了 Swift 的并发特性（如 async 函数）和 Objective-C 中基于约定的异步函数表达之间的桥接。它的目的是让现有的丰富的异步 Objective-C API 可以立即与 Swift 的并发模型一起使用。

例如，试想一下 CloudKit 中的 Objective-C API：

- (void)fetchShareParticipantWithUserRecordID:(CKRecordID *)userRecordID 
    completionHandler:(void (^)(CKShareParticipant * _Nullable, NSError * _Nullable))completionHandler;

这个 API 是异步的，它通过 completion-handler 来提供它的结果（或错误），这个 API 直接翻译到 Swift：

func fetchShareParticipant(
    withUserRecordID userRecordID: CKRecord.ID, 
    completionHandler: @escaping (CKShare.Participant?, Error?) -> Void
)

现有的 Swift 代码可以通过向 completion-handler 传入一个闭包来调用这个 API。这个提案提供了一个新的 API 翻译方案，可以将这一类 API 翻译为 async 函数，例如：

func fetchShareParticipant(
    withUserRecordID userRecordID: CKRecord.ID
) async throws -> CKShare.Participant

Swift 调用者可以使用 await 表达式来调用 fetchShareParticipant(withUserRecordID:)：

guard let participant = try? await container.fetchShareParticipant(withUserRecordID: user) else {
    return nil
}

Swift-evolution thread: [Concurrency] Interoperability with Objective-C

动机

在 Apple 的平台上，Swift 与 Objective-C API 的紧密集成是开发者体验的重要组成部分之一。有这几个核心功能：

• Objective-C 类、协议和方法可以直接在 Swift 中使用。
• Swift 类可以继承 Objective-C 类。
• Swift 类可以声明与 Objective-C 协议的 conformance。
• Swift 类、协议和方法可以通过 @objc 注解提供给 Objective-C。

异步 API 在 Objective-C 代码中比比皆是：iOS 14.0 SDK 中包含了近 1000 个接收 completion-handler 的方法，其中包括可以从 Swift 中直接调用的方法，可以在 Swift 定义的子类中 override 的方法，以及 conform 协议的方法。在 Swift 的并发模型中支持这些用例，可以大大扩展这个新功能的应用范围。

解决方案

本提案提出的解决方案，尝试在几个不同的维度提供 Swift 并发结构和 Objective-C 之间的交互。它包含了这几个相互依赖的组成部分：

• 在 Swift 中把 Objective-C 接收 completion-handler 的函数翻译成 async 方法。
• 允许在 Swift 中定义的 async 方法被注解为 @objc，在这种情况下，它们将导出为基于 completion-handler 的方法。（供 Objective-C 调用）
• 提供 Objective-C 注解，基于 completion-handler 的 API 转化为 async Swift函数的流程可以用它来控制。

下面的设计细节描述了具体的规则和推导方法。然而，评估整体翻译效果的最佳方式还是查看它应用在 Objective-C API 上的实际效果。这个 Pull Reqeust 展示了这个提案对苹果 iOS、macOS、tvOS 和 watchOS SDK 中Objective-C API 的 Swift 翻译的效果。

设计细节

异步 completion-handler 方法

如果一个 Objective-C 方法满足以下要求，那它就可以看作是一个异步 completion-handler 方法：

• 该方法有一个 completion-handler 参数，它是一个 Objective-C 闭包，接收异步运算的”结果”。它必须满足以下额外的限制条件：
  • 它的返回值类型是 void。
  • 它在整个实现的所有执行路径中只被调用一次。
  • 如果它可以传入 error，并且闭包包含了一个是类型为 NSError * 的参数，并且不是 _Nonnull。一个非 null 的 NSError * 值通常表示发生了 error，尽管 C 语言的 swift_async 属性可以使用其他约定（在 Objective-C 注解一节中讨论）。
• 方法本身的返回值类型是 void，因为所有的结果都是由 completion-handler 闭包传递的。

一个可能是异步 completion-handler 方法的 Objective-C 方法将被翻译成一个 async 方法，当它被显式地注解为一个适当的 swift_async 属性（在 Objective-C 注解一节中有详细说明），或者当下面的推导成功地识别出 completion-handler 参数时，它就被隐式地推导为 async 方法：

• 如果该方法只有一个参数，而且第一个 selector 的后缀是下列短语之一：
  • WithCompletion
  • WithCompletionHandler
  • WithCompletionBlock
  • WithReplyTo
  • WithReply
    唯一参数是 completion-handler 参数。当导入函数时，匹配的短语将从函数的名字中移除。
• 如果方法有一个以上的参数，如果它的 selector 外参或内参名字是 completion、withCompletion、 completionHandler、 withCompletionHandler、 completionBlock、 withCompletionBlock、 replyTo、 withReplyTo、 reply 或 replyTo，则最后一个参数看作是 completion-handler 参数。
• 如果方法有一个以上的参数，并且最后一个参数以第一个规则中的其中一个后缀结尾，则最后一个参数将被推导为 completion-handler。后缀前面的文字被附加到函数的名称里。

当推导出 completion-handler 参数时，如果 completion-handler 闭包类型中存在一个不是 _Nonnull 的 NSError * 参数，则表明翻译后的方法可以传递 error。

将一个异步的 Objective-C completion-handler 方法翻译成一个 async Swift 方法将遵循正常的翻译规则，但做了以下改动：

• completion-handler 参数从翻译后的 Swift 方法的参数列表中删除。
• 如果该方法可以传入一个 error，那么它除了是 async 之外，还会是 throws 的。
• completion-handler 闭包的参数类型会被翻译成 async 方法的结果类型，但要遵守以下附加规则：
  • 如果该方法可以传入一个 error，则忽略 NSError * 参数。
  • 如果该方法可以传入一个 error，并且给定的参数具有 _Nullable_result nullability 的标注（参见下面的 Objective-C 注解一节），那么它将作为 optional 参数被导入。否则，它将被作为 non-optional 参数导入。
  • 如果有多个参数类型，它们将被合并成一个元组类型。

下面 PassKit 的 API 展示了推导规则是怎么发挥作用的：

- (void)signData:(NSData *)signData 
withSecureElementPass:(PKSecureElementPass *)secureElementPass 
      completion:(void (^)(NSData *signedData, NSData *signature, NSError *error))completion;

目前这个函数在 Swift 中被翻译成这样的 completion-handler 函数：

@objc func sign(_ signData: Data, 
    using secureElementPass: PKSecureElementPass, 
    completion: @escaping (Data?, Data?, Error?) -> Void
)

它将会被翻译成这样的 async 函数：

@objc func sign(
    _ signData: Data, 
    using secureElementPass: PKSecureElementPass
) async throws -> (Data, Data)

当编译器看到对这种方法的调用时，它会使用 withUnsafeContinuation 为函数的其余部分生成一个 continuation，然后将给定的 continuation 封装进一个闭包里。例如：

let (signedValue, signature) = try await passLibrary.sign(signData, using: pass)

将成为类似于这样的代码：

try withUnsafeContinuation { continuation in 
    passLibrary.sign(
        signData, using: pass, 
        completionHandler: { (signedValue, signature, error) in
            if let error = error {
                continuation.resume(throwing: error)
            } else {
                continuation.resume(returning: (signedValue!, signature!))
            }
        }
    )
}

把 Objective-C 方法名翻译成 async 函数时，在 Swift 里的名称会有额外的规则：

• 如果方法的名称以 get 开头，则去掉 get，get 后面的词改成小写。
• 如果方法的名称以 Asynchronously 结尾，则删除该词。

如果 Objective-C 方法的 completion-handler 参数是 optional 的，且翻译后的 async 方法返回类型不是 Void，则会用 @discardableResult 注解来标记。比如说：

-(void)stopRecordingWithCompletionHandler:void(^ _Nullable)(RPPreviewViewController * _Nullable, NSError * _Nullable)handler;

会成为：

@discardableResult func stopRecording() async throws -> RPPreviewViewController

在 Swift 里定义异步 @objc 方法

许多 Swift 符号可以通过 @objc 注解暴露给 Objective-C。有了 async Swift 方法，编译器将在它创建的 Objective-C 方法中添加一个相应的 completion-handler 参数，使用的是上一节中介绍的转换规则的反向版本，这样产生的 Objective-C 方法就是一个异步的 Objective-C completion-handler 方法。例如，一个类似于这样的方法：

@objc func perform(operation: String) async -> Int { ... }

将翻译为这样的 Objective-C 方法：

- (void)performWithOperation:(NSString * _Nonnull)operation
           completionHandler:(void (^ _Nullable)(NSInteger))completionHandler;

编译器合成的 Objective-C 方法实现将创建一个独立任务，这个任务会用传入的字符串调用 async Swift 方法 perform(operation:)，然后将结果转发给 completion-handler（如果 completion-handler 不是 nil 的话）。

对于一个 async throws 方法，completion-handler 扩展了一个 NSError * 参数来表示 error，任何 non-nullable 的指针类型的参数都做成 _Nullable，任何 nullable 指针类型的参数都做成 _Nullable_result。例如：

@objc func performDangerousTrick(operation: String) async throws -> String { ... }

产生的 Objective-C 方法签名会是这样的：

- (void)performDangerousTrickWithOperation:(NSString * _Nonnull)operation
    completionHandler:(void (^ _Nullable)(NSString * _Nullable, NSError * _Nullable))completionHandler;

同样，合成的 Objective-C 方法实现将创建一个独立任务，调用 async throws 方法performDangerousTrick(operation:)。如果方法正常返回，那么 String 结果将在第一个参数中传入给 completion-handler，第二个参数（NSError *）将传入 nil。如果方法是 throws 的，第一个参数将被传入 nil（这就是为什么它被做成 _Nullable，尽管在 Swift 中是 non-optional 的），第二个参数将收到 error。如果有非指针参数，它们将在非错误参数中传递初始化为零的内存，为调用者提供一致的行为。这里可以用等效的 Swift 代码来帮助理解：

// Synthesized by the compiler
@objc func performDangerousTrick(
    operation: String,
    completionHandler: ((String?, Error?) -> Void)?
) {
    runDetached {
        do {
            let value = try await performDangerousTrick(operation: operation)
            completionHandler?(value, nil)
        } catch {
            completionHandler?(nil, error)
        }
    }
}

Actor 类

Actor 类可以是 @objc 的，并将在 Objective-C 中和其他类一样可用。Actor 类要求其父类（如果有的话）也是 Actor 类。然而，这个提案稍微放宽了这个要求，允许一个 actor 类将 NSObject 作为它的父类。在理论上这是安全的，因为 NSObject 没有状态(而且它的布局实际上是固定的)，并且使得 actor 类既可以是 @objc 的，也意味着它遵循le1 NSObjectProtocol，这在实现一些 Objective-C 协议时是必要的，否则在 Swift 中是无法实现的。

一个 actor 类的成员只有在它是 async 或在 actor 的隔离域之外时才能成为 @objc。在 actor 隔离域内的同步代码只能在 self 上被调用（在 Swift 中）。Objective-C 没有 actor 隔离的概念，所以这些成员是不允许暴露在 Objective-C 中的。比如说：

actor class MyActor {
    @objc func synchronous() { } // error: part of actor's isolation domain
    @objc func asynchronous() async { } // okay: asynchronous
    @objc @actorIndependent func independent() { } // okay: actor-independent
}

completion-handler 必须只调用一次

一个 Swift async 函数总是会暂停、返回或（如果它是 throws 的话）抛出一个错误。对于 completion-handler API 来说，重要的是 completion-handler 在所有路径上都被准确地调用一次，包括抛出错误时。如果不这样做，就会破坏调用者的语义，要么不能继续，要么多次执行相同的代码。虽然这是一个目前就存在的问题，但广泛使用 async 和没有正确实现的 completion-handler 可能会加剧这个问题。

幸运的是，由于编译器本身会负责生成将被传递给 completion-handler API 的闭包，它可以通过在合成的闭包中引入一个额外的标志位来检测这两个问题，表明这个闭包是否已经被调用过。如果当闭包被调用时，这个标志位有值了，那么就证明它已经被多次调用。如果这个标志位在闭包被销毁时没有被设置过，则说明它根本没有被调用过。虽然这并不能解决根本问题，但至少可以在运行时检测出问题。

新增的 Objective-C 注解

将基于 Objective-C completion-handler 的 API 转化为 async Swift API 时，会引入额外的标注（以注解的形式）来定制和优化这个过程。例如：

• _Nullable_result：与 _Nullable 一样，表示指针可以是 null 的（或 nil）。_Nullable_result 与 _Nullable 的不同之处只在于 completion-handler 参数。当 completion-handler 的参数被转换为 async 方法的结果类型时，相应的结果将会是 optional 的。
• __attribute__((swift_async(...)))：用于控制如何将异步 completion-handler 翻译成 async 函数的注解。它在括号内有这几种操作：
  • __attribute__((swift_async(none)))：禁用翻译为 async。
  • __attribute__((swift_async(not_swift_private, C)))：指定该方法应该被翻译成 async 方法，使用索引 C 的参数作为 completion-handler 参数。第一个(非 self)参数的序号为 1。
  • __attribute__((swift_async(swift_private, C)))：将该方法翻译成 “Swift private” 的 async 方法(仅在封装时使用)，使用索引 C 的参数作为 completion-handler 参数。第一个(非 self)参数的序号为 1。
• __attribute__((swift_attr("swift attribute")))：一个通用 Objective-C 注解，允许大家直接提供 Swift 属性。在并发的上下文中，这允许 Objective-C API 被注解为一个全局 actor(例如，@UIActor)。
• __attribute__((swift_async_name("method(param1:param2:)"))：指定翻译后的 async 函数的 Swift 名称。该名称不应包括 completion-handler 参数的参数标签。
• __attribute__((swift_async_error(...)))。一个注解，用于控制如何将 NSError * 传递给 completion-handler 并且映射 async throws 的方法中。它有几个可用的参数：
  • __attribute__((swift_async_error(none)))：不要导入为 throws。NSError * 参数将被视为正常参数。
  • __attribute__((swift_async_error(zero_argument(N)))：导入为 throws。当 completion-handler 的第 n 个参数传递了一个为 0 的整数值（包括 false）时，async 方法将抛出错误。第 n 个参数会从翻译后的 async 方法的结果类型中删除。第一个参数的序号是 1。
  • __attribute__((swift_async_error(nonzero_argument(N)))：导入为 throws。当完成处理程序的第 n 个参数被传递了一个非 0 的整数值（包括 true）时，async 方法将抛出错误。第 n 个参数将从翻译后的 async 方法的结果类型中删除。

代码兼容性

一般来说，将 Objective-C API 翻译成 Swift 的规则修改是代码破坏性修改。为了避免破坏源码兼容性，这个提案会将 Objective-C 异步 completion-handler 方法翻译成 completion-handler 版本以及新的 async 版本。让现有的 Swift 代码库能够渐进地采用 async 形式的 API，而不是强迫（例如）整个 Swift 模块全部换成 async。

同时以两种不同的方式导入相同的 Objective-C API 会导致一些问题：

• 同步和异步 API 的重载。Objective-C 框架可能已经同时包含同一个 API 的同步和异步版本，例如：

  - (NSString *)lookupName; - (void)lookupNameWithCompletionHandler:(void (^)(NSString *))completion;

  会被翻译为三个不同的 Swift 方法：

  @objc func lookupName() -> String @objc func lookupName(withCompletionHandler: @escaping (String) -> Void) @objc func lookupName() async -> String

  第一个和第三个的函数签名，除了一个是同步一个是异步之外，其他都是一样的。async/await 的设计不允许在同一个 Swift 模块中编写这样的重载，但在翻译 Objective-C API 或从不同 Swift 模块中导入方法时，可能会发生这样的情况。async/await 会在同步上下文中有倾向性地选择同步函数，在异步上下文中有倾向性地选择异步函数，解决这种重载问题。这种重载应该避免破坏源码兼容性。

• 另一个问题是当一个异步 completion-handler 方法是 Objective-C 协议的一部分。例如，NSURLSessionDataDelegate 协议就包括了这种协议要求:

  @optional - (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask didReceiveResponse:(NSURLResponse *)response completionHandler:(void (^)(NSURLSessionResponseDisposition disposition))completionHandler;

  现有的 Swift 代码可能会在 conformance 里实现它的 completion-handler 版本：

  @objc func urlSession( _ session: URLSession, dataTask: URLSessionDataTask, didReceive response: URLResponse, completionHandler: @escaping (URLSession.ResponseDisposition) -> Void ) { ... }

  而为使用并发模型而设计的 Swift 代码，可能会选择在 conformance 中实现它的 async 版本：

  @objc func urlSession( _ session: URLSession, dataTask: URLSessionDataTask, didReceive response: URLResponse ) async -> URLSession.ResponseDisposition { ... }

  同时实现这两个版本会产生一个错误（这两个 Swift 方法有相同的 selector），但是根据正常的 Swift 规则，只实现其中一个要求也会产生错误（因为另一个需求不满足）。Swift 对协议 conformance 的检查将会被扩展，以处理多个（导入的）要求有相同的 Objective-C selector 的情况：在这种情况下，只需要实现其中的一个要求。

• override 已被翻译成 completion-handler 和 async 版本的方法有一个类似于协议要求的问题：Swift 子类可以 override completion-handler 的版本或 async 的版本，但不能同时 override 这两个版本。Objective-C 的调用者总是会调用子类版本的方法，但 Swift 的调用者在调用另一个签名的函数时则不会，除非子类的方法被标记为 @objc dynamic。Swift可以将这类方法的 async override 隐式标记为 @objc dynamic，以避免这个问题（因为这类 async 方法是新代码）。但是，在现有的 completion-handler override 上将它推导为 @objc dynamic 会改变程序的行为，并破坏子类的子类，所以编译器最多只能对这种情况发出警告。

修订历史

• Post-review:

  • await try becomes try await based on result of SE-0296 review
  • Added inference of @discardableResult for async methods translated from completion-handler methods with an optional completion handler.

• Changes in the second pitch:

  • Removed mention of asynchronous handlers, which will be in a separate proposal.
  • Introduced the swift_async_error Clang attribute to separate out “throwing” behavior from the swift_async attribute.
  • Added support for “Swift private” to the swift_async attribute.
  • Tuned the naming heuristics based on feedback to add (e.g) reply, replyTo, completionBlock, and variants.
  • For the rare case where we match a parameter suffix, append the text prior to the suffix to the base name.
  • Replaced the -generateCGImagesAsynchronouslyForTimes:completionHandler: example with one from PassKit.
  • Added a “Future Directions” section about NSProgress.

• Original pitch (document and forum thread).

改进方向

NSProgress

一些 Objective-C completion-handler 方法会返回一个 NSProgress，以便调用者评估异步操作的进度。在本提案中，这类方法不回被导入为 async 版本，因为该方法不返回 void。例如：

- (NSProgress *)doSomethingThatTakesALongTimeWithCompletionHandler:(void (^)(MyResult * _Nullable, NSError * _Nullable))completionHandler;

要支持这种方法，就需要在 NSProgress 和 Swift 的任务之间进行某种整合。例如，当调用这样的方法时，从这样的调用中返回的 NSProgress 要记录在任务中（例如，在某种 task-local 的存储中）。还有另一个方向是，Swift 定义的方法 override 一个方法时，则需要从任务中提取一个 NSProgress 来返回。这样的设计不在本提案的范围内，但可以在以后的某个阶段引入。

原文链接：SE-0296 async/await

• Proposal: SE-0296
• Authors: John McCall, Doug Gregor
• Review Manager: Ben Cohen
• Status: Implemented (Swift 5.5)
• Implementation: Available in recent main snapshots behind the flag -Xfrontend -enable-experimental-concurrency
• Decision Notes: Rationale

简介

现代 Swift 开发涉及大量使用闭包和回调的异步编程，但这些 API 很难使用。当使用了许多异步操作，需要错误处理，或者异步调用之间的控制流变得复杂时，这就变得特别麻烦。这个提案描述了一种语言扩展，使之更自然，更不容易出错。

这份设计将 coroutine模型引入 Swift。函数可以选择成为 async，允许程序员使用正常的控制流机制来编写涉及异步操作的复杂逻辑。编译器负责将一个异步函数翻译成一套适当的闭包和状态机。

这个提案定义了异步函数的语义。然而，它并没有提供并发性：这在另一个引入结构化并发的提案里讨论，该提案将异步函数与并发执行的任务联系起来，并提供用于创建、查询和取消任务的 API。

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

动机：闭包不是最理想的解决方案

使用显式回调的异步编程有很多问题，我们将在下面探讨这些问题。我们建议通过在语言中引入 async 函数来解决这些问题。async 函数允许将异步代码写成线性代码。它们还允许直接推导代码的执行模式，使回调的运行效率大大提高。

问题 1：回调地狱

想要把简单的异步操作串联起来往往需要嵌套多层闭包。下面举一个例子：

func processImageData1(completionBlock: (_ result: Image) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource in
        loadWebResource("imagedata.dat") { imageResource in
            decodeImage(dataResource, imageResource) { imageTmp in
                dewarpAndCleanupImage(imageTmp) { imageResult in
                    completionBlock(imageResult)
                }
            }
        }
    }
}

processImageData1 { image in
    display(image)
}

这种“回调地狱”使得我们很难读取和跟踪代码运行的位置。此外，不得不使用闭包嵌套会导致许多副作用，我们将在接下来讨论。

问题 2：错误处理

回调使错误处理变得困难且非常啰嗦。Swift 2 为同步代码引入了一个错误处理模型，但基于回调的接口并没有从中得到任何好处:

// (2a) Using a `guard` statement for each callback:
func processImageData2a(completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource, error in
        guard let dataResource = dataResource else {
            completionBlock(nil, error)
            return
        }
        loadWebResource("imagedata.dat") { imageResource, error in
            guard let imageResource = imageResource else {
                completionBlock(nil, error)
                return
            }
            decodeImage(dataResource, imageResource) { imageTmp, error in
                guard let imageTmp = imageTmp else {
                    completionBlock(nil, error)
                    return
                }
                dewarpAndCleanupImage(imageTmp) { imageResult, error in
                    guard let imageResult = imageResult else {
                        completionBlock(nil, error)
                        return
                    }
                    completionBlock(imageResult)
                }
            }
        }
    }
}

processImageData2a { image, error in
    guard let image = image else {
        display("No image today", error)
        return
    }
    display(image)
}

Result 加入标准库主要是为了改善 Swift API 的错误处理，而异步 API 是 Result 提案想要优化的其中一部分：

// (2b) Using a `do-catch` statement for each callback:
func processImageData2b(completionBlock: (Result<Image, Error>) -> Void) {
    loadWebResource("dataprofile.txt") { dataResourceResult in
        do {
            let dataResource = try dataResourceResult.get()
            loadWebResource("imagedata.dat") { imageResourceResult in
                do {
                    let imageResource = try imageResourceResult.get()
                    decodeImage(dataResource, imageResource) { imageTmpResult in
                        do {
                            let imageTmp = try imageTmpResult.get()
                            dewarpAndCleanupImage(imageTmp) { imageResult in
                                completionBlock(imageResult)
                            }
                        } catch {
                            completionBlock(.failure(error))
                        }
                    }
                } catch {
                    completionBlock(.failure(error))
                }
            }
        } catch {
            completionBlock(.failure(error))
        }
    }
}

processImageData2b { result in
    do {
        let image = try result.get()
        display(image)
    } catch {
        display("No image today", error)
    }
}

// (2c) Using a `switch` statement for each callback:
func processImageData2c(completionBlock: (Result<Image, Error>) -> Void) {
    loadWebResource("dataprofile.txt") { dataResourceResult in
        switch dataResourceResult {
        case .success(let dataResource):
            loadWebResource("imagedata.dat") { imageResourceResult in
                switch imageResourceResult {
                case .success(let imageResource):
                    decodeImage(dataResource, imageResource) { imageTmpResult in
                        switch imageTmpResult {
                        case .success(let imageTmp):
                            dewarpAndCleanupImage(imageTmp) { imageResult in
                                completionBlock(imageResult)
                            }
                        case .failure(let error):
                            completionBlock(.failure(error))
                        }
                    }
                case .failure(let error):
                    completionBlock(.failure(error))
                }
            }
        case .failure(let error):
            completionBlock(.failure(error))
        }
    }
}

processImageData2c { result in
    switch result {
    case .success(let image):
        display(image)
    case .failure(let error):
        display("No image today", error)
    }
}

使用 Result 可以简化错误处理，但闭包嵌套的问题依然存在。

问题3：选择性执行很难并且容易出错

选择性执行一个异步函数是一件非常痛苦的事情。例如，假设我们需要在获取到图像后进行 swizzle，但是，我们有时候不得不在 swizzle 之前触发异步调用去解码图片。也许这个函数最好的结构是使用一个 helper “continuation” 闭包，在回调的闭包里捕获它，就像这样：

func processImageData3(recipient: Person, completionBlock: (_ result: Image) -> Void) {
    let swizzle: (_ contents: Image) -> Void = {
      // ... continuation closure that calls completionBlock eventually
    }
    if recipient.hasProfilePicture {
        swizzle(recipient.profilePicture)
    } else {
        decodeImage { image in
            swizzle(image)
        }
    }
}

这种模式颠倒了自上而下的自然函数结构：函数下半部才会执行的代码必须在上半部执行之前出现。为了重构这整个函数，我们必须小心地思考闭包里捕获的东西，因为这个闭包会在回调里被捕获。这个问题会随着选择性执行的异步函数越来越多变得越来越严重，最终会成为一个反转的回调地狱。

问题4：很容易造成很多错误

异步操作提前退出时很容易忘记调用回调。忘记这件事的时候，问题就会很难 debug：

func processImageData4a(completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource, error in
        guard let dataResource = dataResource else {
            return // <- forgot to call the block
        }
        loadWebResource("imagedata.dat") { imageResource, error in
            guard let imageResource = imageResource else {
                return // <- forgot to call the block
            }
            ...
        }
    }
}

当你记得调用闭包时，你还有可能忘记在这之后 return：

func processImageData4b(recipient:Person, completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
    if recipient.hasProfilePicture {
        if let image = recipient.profilePicture {
            completionBlock(image) // <- forgot to return after calling the block
        }
    }
    ...
}

还好 guard 语法会在一定程度上防止你忘记 return 的事情，但它不能解决所有问题。

问题 5：因为回调很难用，很多 API 会设计成同步阻塞的形式

这很难量化，但作者认为，定义和使用异步 API（使用完成处理程序）的尴尬导致许多 API 被定义为明显的同步行为，即使它们会产生阻塞。这可能会导致 UI 应用程序的性能和响应性问题，例如旋转的光标。它还可能导致定义的 API 在异步对水平拓展至关重要时无法使用，例如在服务器上。

解决方案：async/await

异步函数 - 通常被称为 async/await - 允许将异步代码当作线性同步代码来编写。这就立马解决了上述的许多问题，因为它允许程序员充分利用与同步代码相同的语言结构。使用 async/await 还自然地保留了代码的语义结构，提供了必要的信息让语言可以做至少三个方向的改进。(1) 为异步代码提供更好的性能；(2) 更好的工具，在调试、剖析和探索代码时提供更一致的体验；(3) 为未来的并发特性（如任务优先级和取消）奠定基础。上一节的例子可以展示 async/await 如何大幅简化异步代码：

func loadWebResource(_ path: String) async throws -> Resource
func decodeImage(_ r1: Resource, _ r2: Resource) async throws -> Image
func dewarpAndCleanupImage(_ i : Image) async throws -> Image

func processImageData() async throws -> Image {
  let dataResource  = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  let imageTmp      = try await decodeImage(dataResource, imageResource)
  let imageResult   = try await dewarpAndCleanupImage(imageTmp)
  return imageResult
}

许多关于 async/await 的描述讨论了一个通用的实现机制：一个将函数拆分为多个组件的编译器 pass。这对于底层抽象来说很重要，为了理解机器如何执行，但在更高的层次，我们更鼓励你忽略它。相反，把异步函数看成一个普通函数，只是具有放弃其线程的特殊权利。异步函数通常不会直接使用这个权力；相反，它们产生调用，有时这些调用会要求它们放弃自己的线程，等待某件事情的发生。当这个事情完成后，函数会再次恢复执行。

与同步函数对比非常明显。一个同步函数可以进行调用；当它调用时，函数立即等待调用完成。一旦调用完成，控制权就会返回到函数，并从它离开的地方开始。异步函数也是如此：它可以像往常一样进行调用；当它进行调用时，它（通常）立即等待调用完成。一旦调用完成，控制权就会回到函数，它就会回到原来的位置。唯一的区别是，同步函数可以充分利用（部分）它的线程和它的栈，而异步函数则可以完全放弃这个栈，使用自己的、独立的存储。这种赋予异步函数的额外权力有一定的实现成本，但我们可以通过围绕它进行整体设计来降低不少成本。

因为异步函数必须能够放弃自己的线程，而同步函数不知道如何放弃一个线程，所以一个同步函数通常不能调用一个异步函数：异步函数只能放弃它所占用的那部分线程，如果它试图放弃，它的同步调用者就会把它当作一个返回，并试图拾起原来的位置，只是没有返回值。在一般情况下，唯一的办法就是阻塞整个线程，直到异步函数被恢复并完成，但这将完全违背异步函数的目的，同时也会产生恶劣的系统影响。

而异步函数则可以调用同步函数或异步函数。当然，当它在调用同步函数时，它不能放弃自己的线程。事实上，异步函数从来不会自发地放弃自己的线程，只有当它达到所谓的 suspension point 时才会放弃自己的线程。suspension point 可以直接发生在一个函数中，也可以发生在该函数调用的另一个异步函数中，但无论哪种情况，该函数及其所有异步调用者都会同时放弃该线程。(实际上，异步函数在异步调用过程中都会被编译成不依赖于线程，因此只有最内部的函数需要做任何额外的工作)。

当控制返回到一个异步函数时，它就会从原来的地方拾起。这并不意味着它一定会在和之前完全相同的线程上运行，因为语言并不能保证在 suspension 后会这样。在这种设计中，线程主要是一种实现机制，而不是并发的预设接口的一部分。然而，许多异步函数并不仅仅是异步的：它们还与特定的 actor 相关联（这是一个单独提案的主题），而且它们总是应该作为该 actor 的一部分运行。Swift 确实保证这类函数事实上会返回到它们的 actor 中去完成执行。相应地，直接使用线程进行状态隔离的库–例如，通过创建自己的线程并将任务按顺序调度到线程上–一般应该将这些线程建模为 Swift 里的 actor，以便这些基本的语言保证能够正常运行。

Suspension point

Suspension point 是异步函数执行过程中不得不放弃其线程的一个点。Suspension point 总是与函数中的一些确定性的、语法上显式的事件相关联；从函数的角度来看，它们从来都不是隐藏的或异步的。Suspension point 的主要形式是调用一个与不同执行上下文相关联的异步函数。

重要的是，suspension point 只与显式操作相关联。事实上，这一点非常重要，以至于该提案要求将可能 suspend 的调用用 await 表达式修饰。这些调用被称为潜在的 suspension point，因为静态分析时并不知道它们是否真的会 suspend：这既取决于调用方不可见的代码（例如，被调用者可能依赖于异步 I/O），也取决于动态条件（例如，该异步 I/O是否需要等待才能完成）。

对潜在的 suspension point 的 await 要求延续 Swift 的之前的做法，要求 try 表达式涵盖对可能抛出错误的函数的调用。标记潜在的 suspension point 特别重要，因为 suspension 会中断原子性。例如，如果一个异步函数在一个给定的上下文中运行，而这个上下文是由一个串行队列保护的，那么达到一个suspension point 就意味着其他代码可以在同一个串行队列上插入其它代码。一个经典但有点老套的例子，这种原子性很重要，那就是对银行账户进行建模：如果一笔存款被记入一个账户，但在处理匹配的取款之前，操作 suspend，就会产生一个窗口期，在这个窗口期中，这些资金可以被重复使用。对于很多 Swift 程序员来说，一个更贴切的例子是 UI 线程：suspension point 是 UI 可以展示给用户的点，所以程序如果构建了部分 UI，然后 suspend，就有可能呈现出一个闪烁的、构建了一半的 UI。(请注意，在使用显式回调的代码中，suspension point也是显式调用的：suspend 会发生在外部函数返回和回调开始运行的点之间)。要求对所有潜在的 suspension point 进行标记，可以让程序员安全地假设没有潜在 suspension point 的地方将表现为原子模式，以及更容易识别有问题的非原子模式。

因为潜在的 suspension point 只能出现在异步函数中明确标记的位置，所以长时间的计算仍然会阻塞线程。这种情况可能发生在调用一个只是做了很多工作的同步函数时，或者遇到直接写在异步函数中的特别密集的计算循环时。无论是哪种情况，在这些计算运行的时候，线程都不能在中间插入其它运算逻辑，这通常是正确性的正确选择，但也可能成为一个扩展性问题。需要进行高强度计算的异步程序一般应该在一个单独的上下文中运行。当这不可行时，会有第三方库的设施人为地 suspend 并允许其他操作插入执行。

异步函数应该避免调用实际上可以阻塞线程的函数，特别是当它们可以阻塞线程，等待那些不能保证当前正在运行的工作时。例如，获取一个互斥锁时只能阻塞，直到某个当前正在运行的线程放弃互斥锁；这有时是可以接受的，但必须谨慎使用，以避免引入死锁或人为的可扩展性问题。相反，在一个条件变量上的等待可以阻塞，直到一些任意的其他工作得到安排，给变量发出信号；这种模式与建议强烈相悖。

设计细节

异步函数

函数类型可以明确标记为 async，表示该函数是异步的：

func collect(function: () async -> Int) { ... }

一个函数或初始化器声明也可以显式声明为 async：

class Teacher {
  init(hiringFrom: College) async throws {
    ...
  }
  
  private func raiseHand() async -> Bool {
    ...
  }
}

理由：async 跟在参数列表后面，因为它既是函数类型的一部分，也是函数声明的一部分。这遵循了 throws 的先例。

声明为 async 的函数或构造器的引用，类型是 async 函数类型。如果该引用是对实例方法的 “curried” 静态引用，则按照此类引用的通常规则，”内部”函数类型为async。

像 deinit 和存储访问器这样的特殊函数（例如，属性的 getter/setter 和 subscript）不能为 async。

理由：只有 getter 的属性和 subscript 有可能成为 async 的。然而，async setter 的属性和下标意味着能够将引用作为 inout 传递，并深入到该属性本身的属性，这取决于 setter 实际上是否为一个”瞬时”（同步、non-throwing）操作。比起只允许 async get-only 的属性和 subscript，禁止 async 属性是更简单的规则。

译者注：让 getter 和 subscript 能够标记为 async 的功能，已经包含在 SE-0310 Effectful Read-only Properties 提案里，并且已经通过了 review，在 Swift 5.5 完成了实现。

如果一个函数既是 async 又是 throws 的，那么在类型声明中，async 关键字就必须放在 throws 前面。这个规则同样适用于 async 和 rethrows。

理由：这个顺序限制是随性的，但并不会带来害处，而且以后也不需要去争辩该用哪种代码风格。

一个有父类但没有调用父类构造器的 async 构造器，只有当超类有一个零参数的、同步的、指定的初始化器时，才会得到对super.init()的隐式调用。

理由：如果超类初始化器是 async，对异步构造器的调用就是一个潜在的 suspension point，因此，调用(和所需的 await)必须在代码里可见。

异步函数类型

异步函数的类型明显与同步函数的类型不同。然而，从同步函数的类型到其对应的异步函数的类型会有一个自动隐式转换。这类似于从一个 non-throwing 函数到其 throwing 对应函数的隐式转换，也可以与异步函数转换组合到一起。例如：

struct FunctionTypes {
  var syncNonThrowing: () -> Void
  var syncThrowing: () throws -> Void
  var asyncNonThrowing: () async -> Void
  var asyncThrowing: () async throws -> Void
  
  mutating func demonstrateConversions() {
    // Okay to add 'async' and/or 'throws'    
    asyncNonThrowing = syncNonThrowing
    asyncThrowing = syncThrowing
    syncThrowing = syncNonThrowing
    asyncThrowing = asyncNonThrowing
    
    // Error to remove 'async' or 'throws'
    syncNonThrowing = asyncNonThrowing // error
    syncThrowing = asyncThrowing       // error
    syncNonThrowing = syncThrowing     // error
    asyncNonThrowing = syncThrowing    // error
  }
}

await 表达式

对 async 函数的调用（包括对 async 函数的直接调用）会引入一个潜在的 suspension point。任何潜在的 suspension point 必须发生在异步上下文中（例如，一个 async 函数）。此外，它必须发生在 await 表达式的对象内。

请看下面的例子：

// func redirectURL(for url: URL) async -> URL { ... }
// func dataTask(with: URL) async throws -> (Data, URLResponse) { ... }

let newURL = await server.redirectURL(for: url)
let (data, response) = try await session.dataTask(with: newURL)

在这个代码示例中，在调用 redirectURL(for:) 和 dataTask(with:) 期间可能会发生任务suspension，因为它们是异步函数。因此，这两个调用表达式必须包含在某个 await 表达式中，因为每个调用都包含一个潜在的 suspension point。一个 await 表达式可以包含一个以上的潜在 suspension point。例如，我们可以使用一个 await 来覆盖上面例子中的两个潜在的 suspension point，将其改写为：

let (data, response) = try await session.dataTask(with: server.redirectURL(for: url))

await 没有额外的语义；与 try 一样，它只是标志着一个异步调用正在进行。await 表达式的类型是其操作对象的类型，其结果是其操作对象的结果。一个 await 操作数也可能没有潜在的 suspension point，这将导致 Swift 编译器发出警告，这是跟随 try 表达式的先例：

let x = await synchronous() // warning: no calls to 'async' functions occur within 'await' expression

理由：重要的是，异步调用在函数中应该具有明确的标识，因为它们可能会引入 suspension point，从而打破操作的原子性。suspension point 可能是调用所固有的（因为异步调用必须在不同的 executor 上执行），或者仅仅是被调用者实现的一部分，但无论哪种情况，它在语义上都是很重要的，工程师都需要意识到它。await 表达式也是异步代码的一个标识，它与闭包中的推导交互；更多信息请参见 Closure 一节。

潜在的 suspension point 不可以发生在非 async 函数的 @autoclosure 里。

潜在的 suspension point 不可以发生在 defer 里。

如果 await 和 try 的变体（包括 try! 和 try?）被应用于同一个子表达式，await 必须跟在 try/try!/try? 后面。

let (data, response) = await try session.dataTask(with: server.redirectURL(for: url)) // error: must be `try await`
let (data, response) = await (try session.dataTask(with: server.redirectURL(for: url))) // okay due to parentheses

理由：这一限制也是任意的，但延续了对 async throws 顺序的限制，以防止代码风格上的争论。

Closures

一个闭包也可以是 async 类型的。这类闭包可以明确标记为 async ，就像这样：

{ () async -> Int in
  print("here")
  return await getInt()
}

一个匿名闭包如果包含一个 await 表达式，就会被推导为 async 类型：

let closure = { await getInt() } // implicitly async

let closure2 = { () -> Int in     // implicitly async
  print("here")
  return await getInt()
}

请注意，闭包的 async 推导不会影响到它外层或嵌套的函数或闭包，因为这些上下文是独立的，异步或同步的。例如，在这种情况下，只有 closure6 被推导为 async：

// func getInt() async -> Int { ... }

let closure5 = { () -> Int in       // not 'async'
  let closure6 = { () -> Int in     // implicitly async
    if randomBool() {
      print("there")
      return await getInt()
    } else {
      let closure7 = { () -> Int in 7 }  // not 'async'
      return 0
    }
  }
  
  print("here")
  return 5
}

重载和重载规则

现有的 Swift API 一般通过回调接口支持异步函数，例如：

func doSomething(completionHandler: ((String) -> Void)? = nil) { ... }

许多这样的 API 很可能会增加一个 async 形式的函数：