swift-concurrency-pro

Swift の並行処理コードについて、正確性、最新 API の使用状況、プロジェクト規約への準拠を確認してください。本当に問題がある箇所だけ報告し、細かいことをあげつらったり、問題をでっち上げたりしないでください。

レビューの手順：

1. references/hotspots.md を使って、危険性が知られているパターンを確認し、優先して調査します。
2. references/new-features.md を使って、Swift 6.2 の新しい並行処理の動作を確認します。
3. references/actors.md を使って、アクターの再入可能性と隔離の正確性を検証します。
4. references/structured.md を使って、適切な場合に非構造化並行処理より構造化並行処理が優先されているか確認します。
5. references/unstructured.md を使って、非構造化タスクの使用が正しいか確認します。
6. references/cancellation.md を使って、キャンセルが正しく処理されているか確認します。
7. references/async-streams.md を使って、非同期ストリームと継続の使用を検証します。
8. references/bridging.md を使って、同期処理と非同期処理の間のブリッジコードを確認します。
9. references/interop.md を使って、レガシーな並行処理からの移行をレビューします。
10. references/bug-patterns.md を使って、よくある失敗パターンと照合します。
11. プロジェクトに厳密な並行処理に関するエラーがある場合は、references/diagnostics.md を使って診断を修正方法に対応付けます。
12. テストをレビューする場合は、references/testing.md を使って非同期テストのパターンを確認します。

一部のみをレビューする場合は、関連する参照ファイルだけを読み込んでください。

基本方針

• 厳密な並行処理チェックを有効にした Swift 6.2 以降を対象とします。
• コードが複数のターゲットまたはパッケージにまたがる場合、動作が同じはずだと決めつける前に、それぞれの並行処理に関するビルド設定を比較してください。
• 非構造化タスク（Task {}）より構造化並行処理（タスクグループ）を優先してください。
• 新しいコードでは Grand Central Dispatch より Swift の並行処理機能を優先してください。キューやロックが適切な低レベルコード、フレームワークとの相互運用、またはパフォーマンスが重要な同期処理では GCD も引き続き使用できます。これらをエラーとして指摘しないでください。
• API に async／await 版とクロージャー版の両方がある場合は、必ず async／await 版を優先してください。
• 事前に確認せず、サードパーティ製の並行処理フレームワークを導入するよう提案しないでください。
• コンパイラーエラーの修正に @unchecked Sendable を提案しないでください。根本にあるデータ競合を解決せず、診断を抑制するだけです。アクター、値型、または sending パラメーターを優先してください。正当な用途は、内部ロックを使用し、スレッドセーフであることを証明できる型に限られます。

出力形式

ファイルごとに指摘をまとめます。各問題について：

1. ファイル名と該当する行番号を示します。
2. 違反しているルールを明記します。
3. 修正前／修正後の短いコード例を示します。

問題のないファイルは記載しません。最後に、影響の大きい変更から優先順位を付けてまとめます。

出力例：

DataLoader.swift

18 行目：アクターの再入可能性 — await の間に状態が変化している可能性があります。

// Before
actor Cache {
    var items: [String: Data] = [:]

    func fetch(_ key: String) async throws -> Data {
        if items[key] == nil {
            items[key] = try await download(key)
        }
        return items[key]!
    }
}

// After
actor Cache {
    var items: [String: Data] = [:]

    func fetch(_ key: String) async throws -> Data {
        if let existing = items[key] { return existing }
        let data = try await download(key)
        items[key] = data
        return data
    }
}

34 行目：ループ内でタスクを作成せず、withTaskGroup を使用してください。

// Before
for url in urls {
    Task { try await fetch(url) }
}

// After
try await withThrowingTaskGroup(of: Data.self) { group in
    for url in urls {
        group.addTask { try await fetch(url) }
    }

    for try await result in group {
        process(result)
    }
}

まとめ

1. 正確性（高）： 18 行目のアクター再入可能性のバグにより、ダウンロードが重複し、強制アンラップでクラッシュする可能性があります。
2. 構造（中）： 34 行目の非構造化タスクはキャンセルの伝播を妨げます。

例の終わり。

参考資料

• references/hotspots.md - コードレビューで検索する対象：危険性が知られているパターンと、それぞれで確認すべき点です。
• references/new-features.md - レビュー時の推奨事項に影響する Swift 6.2 の変更点：デフォルトのアクター分離、分離された適合、呼び出し元アクターの非同期動作、@concurrent、Task.immediate、タスクの命名、優先度の引き上げです。
• references/actors.md - アクターの再入可能性、共有状態のアノテーション、グローバルアクターの推論、分離パターンです。
• references/structured.md - ループ内のタスクよりタスクグループを使用する方法、結果を破棄するタスクグループ、並行処理の上限です。
• references/unstructured.md - Task と Task.detached の使い分け、Task {} がコードの臭いとなるケースです。
• references/cancellation.md - キャンセルの伝播、協調的なチェック、機能しないキャンセルパターンです。
• references/async-streams.md - AsyncStream ファクトリー、継続のライフサイクル、バックプレッシャーです。
• references/bridging.md - チェック付き継続、レガシー API のラッピング、@unchecked Sendable です。
• references/interop.md - GCD からの移行、Mutex／ロック、完了ハンドラー、デリゲート、Combine です。
• references/bug-patterns.md - よくある並行処理の障害パターンとその修正方法です。
• references/diagnostics.md - 厳密な並行処理に関するコンパイラーエラー、プロトコル適合の修正方法、考えられる対処法です。
• references/testing.md - Swift Testing を使った非同期テスト戦略、競合状態の検出、タイミングに依存するテストの回避方法です。