DiscardingTaskGroups

新しいタスクグループ型として DiscardingTaskGroup と ThrowingDiscardingTaskGroup を導入します。それぞれ withDiscardingTaskGroup / withThrowingDiscardingTaskGroup で開きます。これらは通常の TaskGroup と似ていますが、次の点が異なります。

• 子タスクが完了した時点で、その結果も Task オブジェクトも 即座に破棄 します。完了タスクが溜まり続けることがありません。
• next() や AsyncSequence 適合を持ちません。子タスクの値を受け取る手段が無いぶん、子タスクの結果型は常に Void に固定されます。

構造化並行性のプリミティブである点は通常のタスクグループと同じで、with[Throwing]DiscardingTaskGroup { body } は本体を抜ける前に、投入された全ての子タスクの完了を必ず待ちます。

基本の使い方

Motivationの例は、次のように書き換えるだけで安全になります。完了した子タスクはすぐに解放されるので、長時間走り続けてもメモリは増えません。

// GOOD, no leaks!
try await withThrowingDiscardingTaskGroup { group in
    while let newConnection = try await listeningSocket.accept() {
        group.addTask {
            handleConnection(newConnection)
        }
    }
}

API

大まかには、TaskGroup から next() 系を取り除いた形になっています。

public struct DiscardingTaskGroup {
  public mutating func addTask(
    priority: TaskPriority? = nil,
    operation: @Sendable @escaping () async -> Void
  )

  public mutating func addTaskUnlessCancelled(
    priority: TaskPriority? = nil,
    operation: @Sendable @escaping () async -> Void
  ) -> Bool

  public var isEmpty: Bool

  public func cancelAll()
  public var isCancelled: Bool
}

public struct ThrowingDiscardingTaskGroup<Failure: Error> {
  public mutating func addTask(
    priority: TaskPriority? = nil,
    operation: @Sendable @escaping () async throws -> Void
  )

  public mutating func addTaskUnlessCancelled(
    priority: TaskPriority? = nil,
    operation: @Sendable @escaping () async throws -> Void
  ) -> Bool

  public var isEmpty: Bool

  public func cancelAll()
  public var isCancelled: Bool
}

どちらも Sendable ではありません（通常のタスクグループと同様）。

エラー伝播とキャンセルの扱い

通常の ThrowingTaskGroup では、子タスクのエラーは try await group.next() や try await group.waitForAll() を書いた場所で再送出されます。ThrowingDiscardingTaskGroup にはこれらのメソッドが無いため、代わりに次のルールに従って 暗黙的 にエラーを扱います。

• 子タスクのいずれかが最初に投げたエラーを記録する。
• その時点で即座にグループ全体をキャンセルし、残りの子タスクにキャンセルを波及させる。
• with[Throwing]DiscardingTaskGroup を抜けるときに、その最初のエラーを再送出する。

つまり「one for all, and all for one」の方針で、一つの子タスクの失敗が兄弟タスク全体の打ち切りにつながります。

try await withThrowingDiscardingTaskGroup { group in
    group.addTask { try boom(1) }
    group.addTask { try boom(2) }
    group.addTask { try boom(3) }
    // 最初に発生したエラーが記録され、メソッドを抜けるときに再送出される。
    // 残りのタスクはキャンセルされる。
}

この自動キャンセルを避けたい場合の方法は次の2つです。

• 子タスクで throw できない withDiscardingTaskGroup（非スローイング版）を使う。エラーは子タスク側で処理する必要があります。
• 子タスク内で do { ... } catch { ... } を使い、グループに伝播させたくないエラーを握り潰すか、必要なものだけ再送出する。

「最初のエラーだけを投げる」という挙動は、情報欠落（2つ目以降のエラーと、キャンセル波及で大量に発生する CancellationError が失われる）と引き換えに、catch MyModuleError のような通常の catch パターンがそのまま使えることを優先した選択です。

Future Directions（speculative）

コミュニティからは「エラーを集約したい」「最初の1件以外も何らかの形で扱いたい」といった要望が挙がっています。将来的には、複数のエラーをフィルタ・集約・破棄する仕組み（エラーフィルタ関数のようなもの）を追加する余地が残されていますが、本提案時点では実利用例を踏まえて後から決める、とされています。