歴史は、Haskell（必要に応じて呼び出す）やScala（名前で呼び出す）などの関数型プログラミング言語に遡り、遅延評価が不必要な計算を防ぎます。Swiftは、このパターンを採用して、パフォーマンスを犠牲にすることなく、アサーションや制御フロー演算子（&&、||）のためのクリーンな構文を可能にしました。問題は、引数の計算が高コストまたは副作用を持つ場合に発生しますが、早期評価は必要性に関係なく実行を強いることになります。
コンパイラは、引数の式をゼロ引数のクロージャー { expression }の内部に明示的にラップすることによって呼び出し元を変換します。このクロージャー（サンク）は、評価された結果の代わりに関数に渡されます。関数本体がパラメータにアクセスするとき、クロージャーを呼び出し、その時点で評価がトリガーされます。ARCに関しては、合成されたクロージャーは外部スコープから変数を参照でキャプチャします。もしautoclosureが@escapingとしてマークされている場合、クロージャーのコンテキストがヒープにアロケートされ、キャプチャされた参照型を保持し、それらのライフタイムを元のスコープを超えて拡張する可能性があります。
重いJSONシリアル化のためのデバッグログ文字列が必要な高頻度取引分析ダッシュボードの開発を考えてみてください。問題は、プロダクションビルドがデバッグログを無効にしていたのに対し、文字列補間log("Data: \(heavyObject.serialize())")が市場のティックごとに実行され、30％のCPUを不必要に消費していたことです。
一つの解決策は、明示的な後続のクロージャーを渡すことでした：log { "Data: \(heavyObject.serialize())" }。これにより評価が遅延され、完璧でしたが、構文が数百の波括弧でコードベースを混乱させ、可読性が低下し、grep検索が難しくなりました。開発者は時折、クロージャー構文を忘れ、誤って早期評価に戻ることもありました。
別のアプローチは、プリプロセッサマクロやビルド構成を使用して、ログコードを完全に削除することでした。これによりランタイムオーバーヘッドは排除されましたが、プロダクションの緊急時にデバッグができなくなり、別のバイナリビルドが必要になり、CI/CDパイプラインが複雑になりました。
選ばれた解決策は、メッセージパラメーターに対して@autoclosureと@escapingを組み合わせて実装しました：func log(_ message: @autoclosure @escaping () -> String)。これにより、元の早期バージョンと全く同じ自然な呼び出し構文が保持され、遅延評価が保証されました。@escapingにより、非同期ログキューへのディスパッチが可能になりましたが、グラフの更新中にビューコントローラを必要以上に保持しないように注意深いキャプチャリスト管理が必要でした。
その結果、プロダクションのCPU使用率は28％削減され、1秒あたり50,000のティックを正常に処理しました。しかし、チームはメッセージクロージャーがself.marketDataを通じてselfを暗黙的にキャプチャすることで保持サイクルを発見し、ナビゲーション遷移中にビューコントローラを生存させていました。明示的なキャプチャリスト[weak self]がこれを解決しましたが、回帰を防ぐためのリントルールが必要でした。
なぜ@autoclosureは変数をデフォルトで値ではなく参照でキャプチャするのか、そしてこれが非同期にクロージャーが実行されるときに予期しない変化につながる場合があるのか？
デフォルトで、Swiftのクロージャーは標準のクロージャーのセマンティクスと一致させるために変数を参照でキャプチャします。@autoclosure @escapingパラメーターが外部スコープからvarをキャプチャし、関数が後でクロージャーを実行するとき（例：バックグラウンドキューで）、呼び出し元と実行時間の間にその変数への変更がクロージャーの内部で見えるようになります。これは、早期評価と異なり、値が呼び出し元で固定されるからです。値のキャプチャを強制するには、キャプチャリストに[val = variable]のように明示的に変数をシャドウイングする必要がありますが、この構文は自動クロージャーとはその暗黙的な性質のためにほとんど使用されません。
コンパイラは、非エスケープの@autoclosureパラメーターをSILレベルでエスケープバリアントと比較してどのように最適化し、これらの最適化にどのような制限がありますか？
Swiftコンパイラは、非エスケープの自動クロージャーをスタック上にコンテキストが割り当てられた直接の関数ポインタとして扱い、呼び出し先がそれを即座に呼び出す場合、関数の特化を通じてクロージャー本体全体をインライン化することができます。これにより、ヒープのアロケートと参照カウントのオーバーヘッドが排除されます。しかし、一度@escapingとしてマークされると、クロージャーはそのコンテキストをヒープにアロケートし、関数のスコープを超えて生存する必要があり、ARCの保持/解放トラフィックが発生します。候補者は時折、非エスケープの自動クロージャーさえも、クロージャーが別の非エスケープ関数に渡される場合に特定の最適化を防ぐことができ、インライン化をブロックする入れ子のサンクチェーンが作成されることを見逃します。
@autoclosureとrethrowsキーワードの間で具体的にどのような相互作用が発生し、なぜこれはAPI設計にとって重要なのか？
関数がrethrowsとしてマークされ、スローする@autoclosureを受け入れるとき、コンパイラは唯一のスローが自動クロージャーの呼び出しから発生することを確認します。これにより、関数は自身がthrowsとマークされることなくエラーを伝播でき、スローしない呼び出し元に対してクリーンなインターフェースを維持します。これは、左側が偽の場合にのみ右側が評価され、スローされるtry lhs || expensiveFailableRhs()のようなショートサーキット演算子を可能にするため、重要です。候補者は、autoclosureにrethrowsが必要で、クロージャーが唯一のスロー要素である必要があることをしばしば見過ごします。関数本体が他のスロー操作を直接実行する場合、コンパイラはrethrowsアノテーションを拒否します。