Usability of global-actor-isolated types

グローバルアクター isolate された型にまつわる3つの使いづらさを、それぞれ次のように緩和します。

• 値型の Sendable な stored property について、モジュール内では var でも暗黙的に nonisolated として扱う。明示的な nonisolated も (unsafe) なしで書ける。
• グローバルアクター isolate された関数・クロージャには @Sendable を暗黙的に推論する。さらに isolate されたクロージャは non-Sendable 値をキャプチャしてよい。
• 非 isolate・非 Sendable なスーパークラスに対して、グローバルアクター isolate されたサブクラスを許可する。ただしそのサブクラスは Sendable にしない。

この変更はupcoming feature flag GlobalActorIsolatedTypesUsability の下で導入され、Swift 6言語モードで既定で有効になります。

値型の var stored property に対する nonisolated 推論

グローバルアクター isolate された値型の Sendable 型 stored property は、同一モジュール内では var であっても暗黙的に nonisolated として扱われます。

@MainActor
struct S {
  var x: Int = 0 // モジュール内では nonisolated として扱える
}

extension S: Equatable {
  static nonisolated func ==(lhs: S, rhs: S) -> Bool {
    return lhs.x == rhs.x // OK
  }
}

モジュールをまたいで同期的にアクセスさせたい場合は、これまで通り nonisolated を明示します。nonisolated(unsafe) は不要です。ただし、一度 nonisolated を公開すると、後から取り除くとクライアントを壊す可能性があるため、将来 computed property に置き換える場合もその accessor は nonisolated にする必要があります。

この推論は stored property にのみ適用されます。property wrapper が付いた property や lazy property は実体が computed property なので、従来通りグローバルアクターに isolate されたままです。

@propertyWrapper
struct MyWrapper<T> { ... }

@MainActor
struct S {
  @MyWrapper var x: Int = 0
}

extension S: Equatable {
  static nonisolated func ==(lhs: S, rhs: S) -> Bool {
    return lhs.x == rhs.x // error
  }
}

グローバルアクター isolate 関数・クロージャへの @Sendable 推論

@MainActor などグローバルアクター属性が付いた関数型・クロージャ型は、自動的に @Sendable として扱われます。

func test(globallyIsolated: @escaping @MainActor () -> Void) {
  Task {
    await globallyIsolated() // OK
  }
}

isolate されたクロージャは常にそのアクター上で実行されるため、キャプチャした値を並行に使うことがなく、別の isolation domain に渡しても安全だからです。

この変更により、@MainActor の付いた関数型は名前マングリングが変わります。影響を受けるのは、グローバルアクター isolate されていて @Sendable ではないAPIを公開している resilient ライブラリです。ただし、そのような型はそもそも実用上ほぼ無意味な組み合わせで、こうしたAPIは @Sendable を付与すべきか、すでに @preconcurrency で互換性を取っている想定です。

non-Sendable 値のキャプチャ

isolate されたクロージャは、暗黙的に @Sendable であっても non-Sendable 値をキャプチャできます。

class NonSendable {}

func test() {
  let ns = NonSendable()

  let closure = { @MainActor in
    print(ns)
  }

  Task {
    await closure() // OK
  }
}

SE-0414 の isolation region に基づく解析により、ns は closure の形成時にメインアクターの region へ transfer されたとみなされ、以後外側で並行アクセスされることはないため安全です。逆に、別の isolation domain（たとえば task-isolated な関数引数）からキャプチャした non-Sendable 値を isolate クロージャに引き込むことはできません。

class NonSendable {}

func test(ns: NonSendable) async {
  let closure = { @MainActor in
    print(ns) // error: task-isolated value 'ns' can't become isolated
              //        to the main actor
  }
  await closure()
}

非 Sendable スーパークラスの isolate サブクラス

非 isolate・非 Sendable なスーパークラスに対して、サブクラスにグローバルアクター isolation を付けることが許可されます。ただし、その場合サブクラスに Sendable 適合は自動付与されず、明示的に Sendable を書くとエラーです。

class NonSendable {
  func test() {}
}

@MainActor
class IsolatedSubclass: NonSendable {
  func trySendableCapture() {
    Task.detached {
      self.test()
      // error: Capture of 'self' with non-sendable type
      //        'IsolatedSubclass' in a `@Sendable` closure
    }
  }
}

スーパークラス由来の非 isolate なミュータブル状態が残っている以上、インスタンス全体を Sendable と名乗らせるわけにはいかないからです。一方、継承・オーバーライドしたメソッドは、スーパークラス側のメソッドの isolation に合わせる必要があります。

class NonSendable {
  func test() { ... }
}

@MainActor
class IsolatedSubclass: NonSendable {
  var mutable = 0
  override func test() {
    super.test()
    mutable += 0
    // error: Main actor-isolated property 'mutable' can not be
    //        referenced from a non-isolated context
  }
}

これは、スーパークラス側の実装が自身の静的な isolation を前提に動いている可能性があるのに加え、サブクラスのインスタンスがスーパークラス型へのアップキャストや existential、あるいはスーパークラスの適合を要求する型パラメータ経由で、isolation を保たない形で呼び出されうるためです。