質問への回答

Swift は defer ステートメントを各レキシカルスコープに接続されたクロージャーサンクスのコンパイラー生成スタックを介して実装しています。コンパイラーが defer ブロックに出会うと、コードをクロージャーに抽出し、現在のスコープのクリーンアップ記録に登録します。スコープからの退出時（通常のフロー、return、throw、または break によって）に、ランタイムはこれらのクロージャーを後入れ先出し（LIFO）順に実行します。このスタック規則により、後に取得されたリソースが最初に解放され、手動での帳簿管理なしに依存関係のチェーンが保持されます。

質問の歴史

リソースのクリーンアップは歴史的に、決定論的なデストラクタや冗長な例外処理に依存してきました。C++ はRAIIを介してオブジェクトのライフタイムにクリーンアップを結びつけ、一方で Java と C# は、クリーンアップロジックを取得コードから分離する明示的な try-finally ブロックを要求します。Go は、オブジェクト指向のオーバーヘッドなしにスコープベースのクリーンアップを提供するために defer ステートメントを導入し、Swift のデザインに影響を与えました。Swift はエラーハンドリングモデルを補完するためにバージョン 2.0 で defer を取り入れ、finally に対する宣言型の代替手段を提供し、guard ステートメントや早期リターンとスムーズに統合されました。

問題

認証、ログ記録、ネットワーク伝送を伴うファイル操作のような複雑な関数は、細心のリソース管理を必要とします。開発者は、すべての return または throw サイトが、ファイルディスクリプタからセキュリティスコープ付きブックマークまで、以前に取得したすべてのリソースを解放することを確認する必要があります。単一のクリーンアップポイントを見逃すと、リークやデッドロックが発生し、順序が不正確（トランザクションログをフラッシュする前にデータベースを閉じる）になるとデータが破損します。手動クリーンアップは関数の複雑さが増すにつれて維持管理が不可能になり、スコープの境界に結びついた自動的で決定論的かつ秩序のあるリソースの廃棄の必要性が生まれます。

解決策

Swift コンパイラーは defer ステートメントを含むスコープのアクティベーションレコードに保存された関数ポインタのスタックに変換します。各 defer は実行中にこのコンパイラによって管理されるスタックにそのサンクをプッシュします。制御フローがスコープの閉じる波括弧に到達するか、退出ステートメントに遭遇すると、挿入されたエピローグコードがスタックを逆順で反復処理し、各サンクを実行します。このメカニズムは、すべての保留中の defer ブロックがエラーが外部の catch スコープに伝播する前に実行されることを保証することにより、Swift のエラーハンドリングと統合されており、退出パスに関係なくクリーンアップが行われることを保証します。

実生活の状況

暗号化されたユーザーデータをエクスポートする iOS アプリケーションを考えてみてください。プロセスは、セキュリティスコープ付きリソース URL を取得し、FileHandle を開き、暗号化されたバイトを書き込み、結果をアップロードします。各ステップは失敗する可能性があり、ファイルディスクリプタや永続的なリソースブックマークが漏れるのを避けるために厳密なクリーンアップが必要です。

解決策 1: すべての退出ポイントでの手動クリーンアップ。

開発者は、すべての return または throw の前に fileHandle.close() と url.stopAccessingSecurityScopedResource() を重複させることができます。このアプローチは脆弱であり、新しいエラー検査を追加すると、複数のサイトの更新が必要になり、レビュアーはクリーンアップ順序が取得順序と一致していることを確認しなければなりません。メンテナンス中に新しい退出ポイントが追加されるたびに、リークのリスクが増加します。

解決策 2: deinit を持つラッパーオブジェクト。

クリーンアップを deinit で実行する ScopeManager クラスを作成すると、ARC に依存します。ただし、ARC はスコープの終了時に即時解放を保証しないため、オブジェクトはオートリリースプールが排出されるか変数が上書きされるまで持続する可能性があります。長時間実行されるループでは、リソースの解放が遅れ、「オープンファイルが多すぎる」というシステムエラーを引き起こすことがあります。

解決策 3: defer ブロック。

チームは各リソースを取得した後に defer ブロックをすぐに宣言しました：

func exportData() throws {
    let url = try acquireResource()
    defer { url.stopAccessingSecurityScopedResource() }
    
    let fileHandle = try FileHandle(forWritingTo: url)
    defer { fileHandle.close() }
    
    let encrypted = try encrypt(data)
    try fileHandle.write(encrypted)
    try upload(fileHandle)
}

暗号化エラーが throw を引き起こしたとき、ランタイムは自動的にファイルハンドルを閉じてそのリソースへのアクセスを停止し、正しい逆順を維持しました。この解決策はその決定論的で近接性があったため選択されました—クリーンアップコードは取得コードの隣に表示されます。

結果:

エクスポート機能は、ファイルディスクリプタリークなしで 10,000 の同時操作でストレステストを通過しました。コードレビューでは、クリーンアップパスが見逃されたケースはゼロであり、プロファイリングは deinit アプローチに比べて即時のリソース解放を示しました。

候補者がよく見逃すこと

質問 1: 関数が fatalError または無限ループで終了する場合、defer ブロックは実行されますか？

いいえ。defer は制御フローがその囲むスコープの終わりに達したときのみ実行されます。fatalError が呼び出されると、プロセスはスコープを積み上げずに即座に終了し、クリーンアップブロックを実行しません。同様に、無限 while ループはスコープの終了を妨げます; ループボディ内部の defer ブロックはイテレーションが完了したときのみ実行されますが、関数レベルの while true ループは関数レベルの defer ブロックを決してトリガーしません。

質問 2: defer が宣言後に変数が変更されたとき、変数キャプチャはどうなりますか？

defer はデフォルトで値ではなく、参照によって変数をキャプチャします。例えば：

var count = 0
defer { print("Deferred: \(count)") }
count = 5
// これは 0 ではなく 5 を印刷します

宣言時の値をキャプチャするために、開発者は明示的なキャプチャリストを使用しなければなりません: defer { [value = currentValue] in ... }。候補者はしばしば defer が宣言時にスナップショットをキャプチャすると仮定し、ループやミューテーションアルゴリズムで論理エラーを引き起こします。

質問 3: defer ブロックが条件分岐の内部にネストされている場合と親スコープでは、実行順序はどうなりますか？

defer ブロックは、表示されるレキシカルスコープに結びついており、関数スコープではありません。if ブロック内の defer はその if ブロックが終了する際に実行されますが、関数が返るときではありません。異なるネストレベルに複数の defer ブロックが存在する場合、最も内側のスコープの defer が、その特定のブロックを出る際に最初に実行されます。これは、すべての defer ブロックが関数の終了時に実行されると期待する開発者にとって、直感に反する順序になります、特に guard ステートメントに defer を絡めると、早期のサブスコープの終了が発生する場合においては。