Day 006 — 所有権の基礎（ムーブセマンティクス）

📚 背景知識（読んでから問題へ）

Day 003では単純な変数のムーブ、Day 004ではVecの要素に対する部分ムーブが禁止されていること、Day 005ではTake & Returnパターンを学びました。今日はDay 004の最後で触れた予告——「構造体（struct）のフィールドは、実は部分的にムーブしてよい」という、Vecとは対照的なルールを掘り下げます。

Vecは部分ムーブ禁止、structは部分ムーブOK

Day 004で見たとおり、Vec<T>は「連続したメモリ領域に穴なくデータが並んでいる」という不変条件を持つため、fruits[i]のような動的インデックスの要素だけを抜き取ることはできませんでした（E0507）。

ところがstructは事情が異なります。

📋 コピーstruct Config {
    name: String,
    path: String,
}

fn print_name(name: String) {
    println!("name: {}", name);
}

fn main() {
    let config = Config {
        name: String::from("app.conf"),
        path: String::from("/etc/app/app.conf"),
    };

    // フィールドアクセスで name だけをムーブする（= 部分ムーブ）
    print_name(config.name);

    // path はまだ有効。部分ムーブされたのは name だけ
    println!("path still valid: {}", config.path);
}

config.nameだけを関数に渡しても、config.pathはそのまま使い続けられます。これはVecでは絶対に許されなかった操作です。

なぜこの違いが生まれるのか

Vecのインデックスiはforループの変数のように実行時にならないと値が決まらない動的な値です。コンパイラは「どの要素がムーブ済みか」を静的に追跡する手段を持たないため、安全のために部分ムーブそのものを禁止しています。

一方structのフィールドはname・pathのようにコンパイル時に個数も名前も固定されています。コンパイラは「config.nameだけがムーブ済みで、config.pathはまだ有効」という状態を型チェックの中で正確に追跡できます。だからこそ、フィールド単位の部分ムーブを安全に許可できるのです。

静的に追跡できるものは部分ムーブを許し、動的にしか分からないものは全体か借用かの二択に倒す——これがRustの一貫した設計判断です。

📝 問題

1. 概念理解課題: 上記のConfigの例で、config.nameを関数に渡した後にconfig.pathは使えるのに、Day 004のfruits[i]（Vec<String>の要素）は同じように部分的に取り出せなかったのはなぜですか。「コンパイル時に静的に追跡できるかどうか」という観点で説明してください
2. 実装課題: 以下を満たすConfig構造体と処理を実装してください
   • フィールドname: String、path: Stringを持つConfigを定義する
   • fn print_name(name: String)という、Stringの所有権を受け取って表示するだけの関数を実装する
   • main内でConfigのインスタンスを作り、print_name(config.name)でnameフィールドだけをムーブし、その後config.pathを（ムーブせずに）表示する
3. デバッグ予測課題: 上記2の処理の直後に、もう一度println!("{}", config.name);を書いてコンパイルしようとするとエラーになります。発生するエラーコード（E0xxx）と、おおまかなメッセージ内容を予想してください
4. 実装課題（メソッド版）: impl Configブロックにfn into_name_and_path(self) -> (String, String)というメソッドを実装してください。これはselfを消費して(name, path)のタプルを返します（＝両方のフィールドを一度に取り出す、フィールド全体の完全な分解）
5. 発展の概念理解（コードは不要）: もしConfigがDropトレイトを実装していたら、フィールド単位の部分ムーブ（問題2のような操作）は禁止されます。なぜだと思いますか？（ヒント: Dropはデストラクタです。構造体全体が破棄されるとき、Rustは全フィールドを正しい順序でDropする責任を負います）

🔍 ヒント（段階的開示）

📋 コピーstruct Config {
    name: String,
    path: String,
}

impl Config {
    fn into_name_and_path(self) -> (String, String) {
        // self.name と self.path をタプルにして返す
    }
}

fn print_name(name: String) {
    println!("name: {}", name);
}

fn main() {
    let config = Config {
        name: String::from("app.conf"),
        path: String::from("/etc/app/app.conf"),
    };

    print_name(config.name); // name フィールドを部分ムーブ
    println!("path still valid: {}", config.path); // path はまだ使える

    // ここで println!("{}", config.name); を書くとどうなるか予想する（実際には書かない）

    let config2 = Config {
        name: String::from("db.conf"),
        path: String::from("/etc/app/db.conf"),
    };
    let (n, p) = config2.into_name_and_path();
    println!("{} @ {}", n, p);
}

✅ 模範解答

📋 コピーstruct Config {
    name: String,
    path: String,
}

impl Config {
    fn into_name_and_path(self) -> (String, String) {
        (self.name, self.path)
    }
}

fn print_name(name: String) {
    println!("name: {}", name);
}

fn main() {
    // --- 実装課題2: フィールド単位の部分ムーブ ---
    let config = Config {
        name: String::from("app.conf"),
        path: String::from("/etc/app/app.conf"),
    };

    print_name(config.name); // config.name だけがムーブされる
    println!("path still valid: {}", config.path); // config.path は無傷なのでそのまま使える

    println!("---");

    // --- 実装課題4: メソッドでself全体を消費する版 ---
    let config2 = Config {
        name: String::from("db.conf"),
        path: String::from("/etc/app/db.conf"),
    };
    let (n, p) = config2.into_name_and_path(); // config2全体がこの呼び出しでムーブされる
    println!("{} @ {}", n, p);

    // config2 はここではもう使えない（into_name_and_pathがselfを消費したため）
    // 一方 config は name フィールドだけがムーブ済みで、path はまだ使える状態のまま
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_into_name_and_path() {
        let config = Config {
            name: String::from("db.conf"),
            path: String::from("/etc/app/db.conf"),
        };
        let (n, p) = config.into_name_and_path();
        assert_eq!(n, "db.conf");
        assert_eq!(p, "/etc/app/db.conf");
    }
}

$ cargo run
name: app.conf
path still valid: /etc/app/app.conf
---
db.conf @ /etc/app/db.conf

$ cargo test
running 1 test
test tests::test_into_name_and_path ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

🪜 Step-by-Step 解説

📋 コピーprint_name(config.name);

📋 コピーprintln!("path still valid: {}", config.path);

📋 コピーfn into_name_and_path(self) -> (String, String) {
    (self.name, self.path)
}

💡 設計思想・なぜこう書くのか

🛑 コンパイルエラーが出た場合

問題2の処理の後に、もう一度config.nameを使おうとした場合のコードです。

📋 コピーfn main() {
    let config = Config {
        name: String::from("app.conf"),
        path: String::from("/etc/app/app.conf"),
    };

    print_name(config.name);
    println!("path still valid: {}", config.path);

    println!("{}", config.name); // ← ここでエラー
}

読み方:

• error[E0382]: Day 005で見たものと同じエラーコードです。「ムーブ済みの値を使おうとした」ことを示します
• use of moved value: config.name: 今回はDay 005のgreetingのような変数全体ではなく、config.nameというフィールド単位でムーブ済みと判定されています。コンパイラがフィールドレベルで有効/無効を追跡している証拠です
• value moved here / value used here after move: それぞれ「ここでムーブが起きた（print_name(config.name)）」「その後ここで使おうとした」を対応付けています

もしconfig.pathではなくconfig変数全体（例えばprintln!("{:?}", config)のようなDerive Debugでの丸ごと表示）を使おうとした場合は、少し文言が異なるエラーになります。

こちらは「configという値の一部（name）が部分ムーブされているため、config全体を借用できない」という意味です。config.pathのようにまだ有効なフィールドを個別に指定してアクセスする分には問題ない、という違いを押さえておくと混乱しません。

修正方法: ムーブ済みのフィールドをもう一度使いたい場合は、そもそも部分ムーブする前に.clone()しておく（let name = config.name.clone();）か、Day 005のTake & Returnパターンのように新しい値を作って再度Configを組み立て直す必要があります。

🌐 他言語との比較

C++との対比が象徴的です。C++でもstd::move(obj.field)によってフィールド単位のムーブは可能ですが、その後obj.fieldへ誤ってアクセスしてしまうバグをコンパイラは検出してくれません。Rustはこの「フィールド単位の有効/無効」をコンパイル時の型チェックの一部として完全に追跡し、誤用を型エラーとして弾く点が根本的に異なります。

🏆 実務での使いどころ

• 設定・リクエストオブジェクトの分解: ConfigやHttpRequestのような複数フィールドを持つ構造体から、特定のフィールドだけを別のコンポーネントに所有権ごと渡したい場面（例: headersだけをロギング処理に渡し、bodyは別のハンドラに渡す）で、部分ムーブは自然に活用されます
• selfを消費するBuilderやコンバータメソッド: into_name_and_pathのようにfn into_xxx(self) -> ...という命名規則（Rustの慣習でinto_接頭辞は所有権を消費する変換を意味します）は、標準ライブラリでもString::into_bytes(self) -> Vec<u8>など頻出します
• デストラクタリング（let Struct { a, b } = value;）との使い分け: 今日はフィールドアクセス（config.name）による部分ムーブを扱いましたが、パターンマッチによる分解（let Config { name, path } = config;）を使うと、一度に複数フィールドをそれぞれ独立した変数へムーブできます。どちらも同じ「フィールド単位の追跡」の上に成り立つ機能です
• Drop実装との設計トレードオフ判断: 独自にリソース管理（ファイルハンドル・コネクションなど）をする型にDropを実装すると、その型は部分ムーブができなくなります。「フィールドを個別に取り出したいAPIを設計したい」場合は、Dropを実装せずに済む設計（リソース解放を明示的なメソッド呼び出しに任せる等）を検討する判断材料になります

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: let Config { name, path } = config;というパターンマッチによる分解を試してみてください。フィールドアクセス（config.name）による部分ムーブと、分解パターンによる同時ムーブがどちらも同じ「フィールド単位の追跡」に基づいていることを確認できます
• 次回予告: 所有権の基礎（ムーブセマンティクス）はここでいったん一区切りです。Day 007以降で借用と参照（& と &mut）へ本格的に進み、「所有権を移動させずにその場で書き換える」ための借用規則（同時可変参照の禁止）を学びます

🎯 自己評価

自分の回答

気づき・メモ