Garden

最近の記事

Rustのdynはいつ出てくる？

9 min read

Prompt

dynは一箇所でしか出てこないかな？

「dyn（ダイン）」について鋭い質問だね！

結論から言うと、dyn は一箇所だけではなく、Rustの「動的ディスパッチ（多態性）」が必要なあらゆる場面に現れるよ！

情報工学を学ぶ君なら、これを**「仮想関数テーブル（vtable）」を呼び出すための合図**だと考えると、めちゃくちゃスッキリ理解できるはずだ。

主に出てくるのは、以下の3つのシーンだよ！🚀

1. トレイトオブジェクトとしての変数宣言

「具体的な型はわからないけど、特定のトレイト（インターフェース）を実装していることだけは保証したい」という時に使う。

Rust

// 「a24zができる何か」を保持したい
let my_tool: Box<dyn MyTrait> = Box::new(SomeStruct);

ここで dyn がつくのは、コンパイラに対して**「実行時に型を特定して、正しいメソッドを呼び出してね！」**とお願いしているからなんだ。

2. 関数の引数や戻り値

複数の異なる型を、一つの型としてまとめて扱いたい時に出てくる。さっきの main 関数のエラー処理の例を覚えているかな？

Rust

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // ...
}

ここでは「Error トレイトを実装しているなら、ファイルエラーでもパースエラーでも何でもいいよ！」という意味で dyn が使われているんだ。

3. 構造体のフィールド

プラグインシステムや、異なる挙動をするオブジェクトをリスト化したい時にも現れる。

Rust

struct App {
    // 異なる挙動を持つ複数のコンポーネントを保持
    components: Vec<Box<dyn Component>>,
}

🔍 「静的」 vs 「動的」 の決定的な違い

情報工学徒として一番押さえておきたいのがこれ！

Rustには多態性を実現する道が2つあるんだ。

  • 静的ディスパッチ（impl Trait / ジェネリクス）:

    コンパイル時に、使われる型ごとに専用のコードを生成する（単態化）。爆速だけど、バイナリサイズが大きくなり、異なる型を一つの Vec に入れることはできない。

  • 動的ディスパッチ（dyn Trait）:

    実行時に「vtable（仮想関数テーブル）」を見て、どの関数を呼ぶか決める。バイナリはコンパクトで柔軟だけど、関数呼び出しにほんの少しオーバーヘッドがかかる。

⚠️ 見落とされがちな視点：dyn になれないトレイト（Object Safety）

実は、どんなトレイトでも dyn をつければいいわけじゃないんだ。**「オブジェクト安全（Object Safe）」**という条件を満たさないといけない。

例えば、**「自分自身の型（Self）を返すメソッド」**を持っているトレイトは、dyn にできない。なぜなら、実行時に具体的な型がわからないと、どれだけのメモリを確保していいか判断できないからだね。これはまさに「コンパイル時にサイズが決定している必要がある」という Rust の鉄の掟に関わっているんだ。

💡 ＋α 豆知識：なぜ Box とセットなの？

君が見る dyn は、ほぼ確実に Box<dyn ...> や &dyn ... のように、**ポインタ（参照）**と一緒に使われているはずだ。

理由はシンプル！ dyn Trait そのものは**「サイズが不定（Unsized）」**だから。

Rustはスタック上のデータのサイズを事前に知る必要があるから、サイズが固定の「ポインタ（住所）」にしてあげないと、変数として扱えないんだね。

Prompt

いかにもジェネリクスの境界ワイルドカード。

あはは、その表現最高だね！Javaを学んでいる君なら、? extends T や ? super T という「境界ワイルドカード」のあの独特な感覚、よく分かるよ。

RustにはJavaのような ? 記号を使ったワイルドカードそのものはないけれど、**「トレイト境界（Trait Bounds）」**がその役割を完璧に、そしてより厳格にこなしているんだ。

「いかにもワイルドカードっぽい」Rustの書き方を、Javaと比較しながら解剖してみよう！

1. ? extends T（共変）相当：impl Trait

Javaで「Animalを継承した何かを受け取りたい」という時の List<? extends Animal>。

Rustでは「このトレイトを実装している型なら何でも来い！」という トレイト境界 を使うよ。

Rust

// Java: void makeSounds(List<? extends Animal> animals)
// Rust: 「Animalトレイトを実装している何か」のジェネリクス
fn make_sounds<T: Animal>(animals: Vec<T>) {
    for a in animals {
        a.speak();
    }
}

あるいは、もっとスッキリ書くならこれ！

Rust

fn make_sounds(animals: Vec<impl Animal>) { ... }

この impl Trait こそが、Javaの ? extends に最も近い「いかにも」な書き方だね。

2. ? super T（反変）はどこへ行った？

ここが情報工学的に面白いポイント。実はRustには、Javaの ? super T に直接相当する機能は存在しないんだ。

なぜ？

Javaの ? super は主に「消費者（Consumer）」、つまり「データを書き込む先」を柔軟にするために使われるよね。

しかし、Rustは**所有権と生存期間（ライフタイム）**を厳格に管理する言語だ。

「ある型、またはその親の型を受け入れるバッファ」という概念は、型システムが静的に解決されるRustにおいては、ジェネリクスとトレイトの組み合わせでほとんどのケースがカバーできてしまうんだよ。

3. 「いかにも」感が出る where 句

ジェネリクスが複雑になってくると、関数名の後ろがワチャワチャするよね。そこで現れるのが where 句。これがまた、いかにも「型に境界を引いてるぜ」って感じがしてカッコいいんだ。

Rust

fn process_data<T, U>(t: T, u: U) -> String
where
    T: Display + Clone,
    U: Serialize + Debug,
{
    // Tは表示できて複製できるやつ、Uはシリアライズできてデバッグ表示できるやつ！
    format!("{:?}", t.clone())
}

💡 見落とされがちな視点：静的 vs 動的

君が「ワイルドカード」と言ったとき、実は2つのパターンが混ざっているかもしれない。

  • コンパイル時に型が決まる場合: 上で挙げた impl Trait やジェネリクス（静的ディスパッチ）。

  • 実行時まで型がバラバラな場合: 前に話した Vec<Box<dyn Animal>>（動的ディスパッチ）。

Javaの List<Animal> は常に後者（参照を保持するだけ）だけど、Rustはデフォルトで前者（中身をキッチリ詰める）を選ぶ。この「デフォルトが静的」という違いが、Rustの実行速度の源泉なんだ。

🏁 まとめ

  • ? extends T impl T または <T: Trait>。

  • ? super T Rustには（ほぼ）ない。必要ならトレイトの継承（Subtrait）で設計する。

  • 境界の羅列 where 句でエレガントに。

Javaのワイルドカードに慣れていると「不便かな？」と思うかもしれないけど、Rustの「境界」は**「何ができるか（行為）」**にフォーカスしているから、慣れると設計の意図がより明確になるはずだよ！

グラフビュー

最近の記事

グラフビュー