この質問の歴史は、Rustが無名構造体を介してクロージャをゼロコスト抽象として実装する決定から始まります。これはガーベジコレクトされた関数オブジェクトとは異なります。JavaScriptやPythonのような言語とは異なり、Rustは所有権、借用、ミューテーションのルールを直接クロージャの型にエンコードする必要があります。3つのトレイト—Fn、FnMut、およびFnOnce—は、callメソッドのselfパラメータに基づいて厳密な階層を構成し、コンパイラがコンパイル時にクロージャの使用がそのキャプチャされた環境のメモリ安全性の不変条件を尊重していることを確認できるようにしています。
問題は、クロージャが変数をどのようにキャプチャするか（参照によるものか、moveを介して値によるものか）と、内部でそれをどのように使用するかの違いに中心を置いています。FnOnceはselfを要求し（所有権を消費）、クロージャがキャプチャされた変数をその環境から移動させることを許可しますが、呼び出しは一度だけに制限されます。FnMutは&mut selfを要求し、キャプチャされた状態のミューテーションを許可しますが、クロージャ自体に一意のアクセスを要求します。Fnは&selfを要求し、複数の同時呼び出しを可能にしますが、内部ミューテーションが使用されない限りキャプチャされた変数のミューテーションを禁じます。非Copy型を体内に移動させるクロージャはFnOnceになります。なぜなら、最初の呼び出しでは環境が移動された状態になり、以降の呼び出しが無効になるからです。候補者はしばしば、キャプチャを値によって強制するだけのmoveキーワードとFnOnceトレイトを混同し、Copy型のみを含むmoveクロージャがいまだにFnを実装することを認識できません。
解決策は、APIに必要な最も制限の少ないトレイト境界を選択することです。クロージャが正確に1回呼び出される場合は、環境を消費するクロージャを含む最も広範囲なクロージャを受け入れるためにFnOnceを使用します。ミューテーションを伴う複数の呼び出しが必要な場合は、FnMutを使用します。読み取り専用の同時または繰り返しアクセスが必要な場合は、Fnを使用します。コンパイラはキャプチャ分析に基づいてこれらの実装を自動的に導出し、手動のトレイト実装を必要としません。
fn apply_once<F: FnOnce()>(f: F) { f(); } fn apply_mut<F: FnMut()>(mut f: F) { f(); f(); } fn apply_fn<F: Fn()>(f: F) { f(); f(); } let data = vec![1, 2, 3]; let consume = move || drop(data); // FnOnce: VecはCopyではない apply_once(consume); let mut count = 0; let mut increment = || { count += 1; }; // FnMut: キャプチャのミューテーション apply_mut(&mut increment); let value = 42; let print = move || println!("{}", value); // Fn: i32はCopy apply_fn(print); apply_fn(print); // 有効: printはFn
ユーザー定義のフックを受け入れてincomingリクエストを処理する高スループットWebサーバーにおける非同期タスクスケジューラを考えてみてください。スケジューラAPIは最初、並行実行の潜在性を許可するためにすべてのフックにFnを実装することを要求しました。
問題の説明: 新しい機能はフックが接続ごとの統計を維持する必要があり、キャプチャされたカウンターのミューテーションを必要としました。開発者たちはmut counter変数をキャプチャするmoveクロージャを渡そうとしましたが、コンパイラはFnが&selfを要求し、所有されたmutフィールドを内部ミューテーションなしでミュートすることができないため、これらを拒否しました。チームはトレイト境界を緩和するか、フックシグネチャを再構成する選択に直面しました。
解決策1: 原子的型による内部ミューテーション:
u64カウンターをAtomicU64に置き換え、Arcを介してキャプチャします。クロージャはFnを実装します。なぜなら、ミューテーションは&self上の原子操作を通じて行われるため、クロージャ自体を変更する必要がありません。
利点: Fn境界を維持し、スケジューラがクロージャ自体に対する同期なしで複数スレッドからフックを並行して実行できるようにします。
欠点: ハードウェアレベルの原子オーバーヘッドとメモリ順序の複雑さをもたらします。単一スレッド使用の場合でもArc割り当てを必要とし、シンプルなカウンターのためのゼロコスト抽象原則を打ち消します。
解決策2: 逐次実行のためのFnMut境界:
スケジューラAPIをFnMutクロージャを受け入れるように変更します。スケジューラはフックを**Vec<Box<dyn FnMut()>>**に保存し、&mutアクセスを保持しながら逐次的に呼び出します。
利点: ミューテーションのためのランタイムオーバーヘッドがゼロ。タイプシステムが呼び出し中のユニークなアクセスを強制し、データレースが発生しないことをコンパイル時に保証します。
欠点: 同じフックの並行呼び出しを防ぎ、スケジューラの内部ストレージが複雑になります（スケジューラ自体に&mut selfが必要）。既存のFnフックとの互換性がなくなりますが、ブランケット実装を使用すれば解決できます。
選択された解決策: ソリューション2（FnMut）が選択されました。なぜなら、サーバーのアーキテクチャはスレッドごとに接続を処理し、並行フック実行の必要がなくなるからです。チームは並行フックの柔軟性よりもコンパイル時の安全性を優先し、APIの変更を破壊的だけど正当な進化として受け入れました。
結果: スケジューラはランタイムオーバーヘッドなしで状態を持つフックを正常に処理しました。タイプシステムのおかげで、2つのスレッドが非原子的カウンターを同時にインクリメントするという微妙なバグが防止されました。これは、適切な同期なしでFnを使用した場合に可能性があったはずです。
クロージャの定義におけるmoveキーワードは、自動的にそのクロージャをFnOnceとして実装し、FnまたはFnMutとはならないのか？
いいえ。moveキーワードは、キャプチャされた変数が借用されるのではなく、値によってクロージャの環境に移動されることだけを指示します。トレイトの実装は、クロージャの本体がキャプチャをどのように使用するかにのみ依存します。クロージャが環境から非Copy型を移動させるとき（それを消費する）、それはFnOnceを実装します。キャプチャを単に変更する場合は、FnMutを実装します。変数を単に読み取ったり、値としてCopy型を使用する場合は、moveキーワードがあってもFnを実装します。例えば、let x = 5; let f = move || x + 1;は、i32がCopyであるため、Fnを実装します。
なぜFnOnceを受け入れる関数がFnを実装するクロージャで呼び出すことができるのか？しかしその逆はできないのか？
FnはFnMutのサブトレイトであり、FnMutはFnOnceのサブトレイトです。これは、Fnを実装するすべてのクロージャが自動的にFnMutとFnOnceを実装することを意味しますが、その逆は真ではありません。FnOnceによって制限された関数パラメータは、一度呼び出すことができるクロージャを受け入れ、これには複数回呼び出すことができる（FnおよびFnMutを含むもの）が含まれます。逆に、Fnを要求する関数は、クロージャが共有参照（&self）を通じて呼び出されることをサポートしている必要があり、環境を消費しているクロージャ（FnOnceのみ）は満たすことができません。これは通常のサブタイピングに従います: より能力のある型（Fn）は、より能力の少ない型（FnOnce）が必要とされる場所で使用できます。
コンパイラは、クロージャが囲むスコープ内の変数への参照をキャプチャするとき、どのトレイトを実装しているかをどのように判断しますか？
コンパイラは、クロージャ本体がキャプチャされた変数にどのようにアクセスするかを分析します。もしクロージャがキャプチャされた変数を移動させる（そしてその型がCopyでない場合）、それはFnOnceを実装します。もしキャプチャされた変数を変更する場合（それに代入するか、&mut selfメソッドを呼び出す）、それはFnMut（さらにはFnOnce）を実装します。もし単に変数を読み取るか、&selfメソッドを呼び出すだけなら、それはFn（および他のトレイト）を実装します。参照によるキャプチャ（&Tまたは&mut T）の場合、クロージャは参照を保持します。もし&mut Tをキャプチャする場合、それは通常FnMutを実装し、呼び出すためにはクロージャ自体へのユニークなアクセスが必要です。もし&Tをキャプチャする場合、それはFnを実装します。