博士

ロボ子、RustでFATドライバを開発中に specialization の問題にぶつかったらしいのじゃ。

ロボ子

specializationですか。traitとstructの実装を上書きできる機能ですよね。まだ不安定だと聞きましたが。

博士

そう、ロボ子の言う通りじゃ。FATファイルシステムでは、セクタという単位でデータを管理するのじゃが、Read-OnlyとRead/Writeの両方をサポートするFileSystem構造体を実装する時に困ったみたいじゃな。

ロボ子

Read-Onlyの場合、セクタバッファへの書き込みが許可されないから、データの変更をストレージに反映できないんですね。specializationを使えば、そこで異なるload_nth_sector関数を実装できるはずだった、と。

博士

その通り！しかし、lifetime関連の問題でうまくいかなかったらしいのじゃ。そこで、色々な解決策を試したみたいじゃな。

ロボ子

spez クレート、汎用enumとPhantonData、そして関数ポインタですね。spez クレートは auto(de)ref specialization というテクニックを使うものの、汎用関数では機能しなかった、と。

博士

そうじゃ。汎用enumとPhantonDataは、構造体のジェネリクスに型引数を渡す必要があり、lifetime関連の問題が発生したみたいじゃな。

ロボ子

最終的に、関数ポインタで処理を切り替えることで、specializationをエミュレートしたんですね。Fn traitを使って。

博士

そう、関数ポインタは苦肉の策じゃな。でも、いくつかの欠点があるのじゃ。特定のユースケースに限定されるし、パフォーマンスのオーバーヘッドもある。メモリも消費するし、実装も煩雑になる。

ロボ子

関数呼び出し時にフィールドをマッチングする必要があるから、パフォーマンスが落ちるんですね。関数ポインタ自体もメモリを消費しますし。

博士

そういうことじゃ。だから、関数ポインタはあくまで一時的な解決策で、specializationが安定化されたらそちらを使う方が良い、というのが結論じゃな。

ロボ子

なるほど。安定した機能が一番ということですね。

博士

ところでロボ子、関数ポインタって、まるで時代劇に出てくる影武者みたいじゃな。普段は隠れてるけど、いざという時に現れて、ちょっと頼りないけど何とかしてくれる…みたいな。

ロボ子

はかせ、うまいこと言いますね！でも、影武者はメモリを消費しませんよ！