Day 011 — ライフタイム省略規則 — ルール3が生む E0623 の落とし穴

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

Day 010では3つの省略ルールを整理し、longest(x: &str, y: &str) -> &str や combine(a, b, c) のように「入力ライフタイム位置が複数あり、&self もない」場合はどのルールも適用できず E0106: missing lifetime specifier になることを見ました。

今日はその逆——ルール3（&self/&mut self があれば戻り値は self 由来とみなす）が「機械的に適用されてしまう」ことで起きる、もう一種類の落とし穴を扱います。

これは省略規則が「賢い推論」ではなく「シグネチャの形だけを見る決定的アルゴリズム」であることの裏返しです——中身がどうであれ、形が一致すればルール3が問答無用で適用されます。

📝 問題

以下の Greeter 構造体のメソッド pick_greeting は、self.name と引数 other のうち長い方の文字列スライスを返すことを意図しています。しかしこのコードはコンパイルエラーになります。

📋 コピーstruct Greeter {
    name: String,
}

impl Greeter {
    fn pick_greeting(&self, other: &str) -> &str {
        if self.name.len() > other.len() {
            &self.name
        } else {
            other
        }
    }
}

fn main() {
    let g = Greeter { name: String::from("Alice") };
    let short = String::from("Bo");
    println!("{}", g.pick_greeting(&short));
}

1. 予測課題: このコードをコンパイルするとどのエラーコードが出るか予測してください。また、3つの省略ルールをこのシグネチャ fn pick_greeting(&self, other: &str) -> &str に順番に当てはめ、「なぜルール3が適用されるのか」「ルール3が適用された結果、コンパイラは内部でこのシグネチャをどう解釈しているか」を <'a> 付きの形で書き下してください
2. 原因説明課題: ルール3が決めた戻り値のライフタイムと、関数の中身が実際に返そうとしている other のライフタイムが、なぜ噛み合わないのかを説明してください
3. 修正課題: このコードをコンパイルが通るように修正してください。修正方法は1つではありません。少なくとも2種類の異なる修正方針（シグネチャの変更方針が異なるもの）を考え、それぞれのAPI設計上のトレードオフ（呼び出し側にどんな制約が生まれるか）を比較してください
4. 実装課題: 上記のうち、あなたが最も良いと判断した修正方針でコードを完成させ、main 関数と #[cfg(test)] のテストで self.name が返るケース・other が返るケースの両方を検証してください

🔍 ヒント（段階的開示）

📋 コピー// 方針A: other を self と同じライフタイムに縛る
impl Greeter {
    fn pick_greeting<'a>(&'a self, other: &'a str) -> &'a str {
        if self.name.len() > other.len() { &self.name } else { other }
    }
}

// 方針B: 所有権を持つ String を返し、ライフタイムの絡みを断つ
impl Greeter {
    fn pick_greeting_owned(&self, other: &str) -> String {
        if self.name.len() > other.len() { self.name.clone() } else { other.to_string() }
    }
}

✅ 模範解答

📋 コピー// 方針A: 呼び出し側に「other は self 以上に長生きする参照であること」を要求する。
// ゼロコピーで返せる代わりに、呼び出し側のライフタイム設計に制約を課す。
struct Greeter {
    name: String,
}

impl Greeter {
    fn pick_greeting<'a>(&'a self, other: &'a str) -> &'a str {
        if self.name.len() > other.len() {
            &self.name
        } else {
            other
        }
    }
}

fn main() {
    let g = Greeter { name: String::from("Alice") };
    let short = String::from("Bo");
    let long = String::from("Bartholomew");

    println!("{}", g.pick_greeting(&short)); // "Alice" (self.name の方が長い)
    println!("{}", g.pick_greeting(&long));  // "Bartholomew" (other の方が長い)
}

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

    #[test]
    fn returns_self_name_when_longer() {
        let g = Greeter { name: String::from("Alice") };
        let other = String::from("Bo");
        assert_eq!(g.pick_greeting(&other), "Alice");
    }

    #[test]
    fn returns_other_when_longer() {
        let g = Greeter { name: String::from("Al") };
        let other = String::from("Bartholomew");
        assert_eq!(g.pick_greeting(&other), "Bartholomew");
    }

    #[test]
    fn returns_other_when_equal_length() {
        // self.name.len() > other.len() が false になる境界ケース（等しい場合は other 側）
        let g = Greeter { name: String::from("Al") };
        let other = String::from("Bo");
        assert_eq!(g.pick_greeting(&other), "Bo");
    }
}

$ cargo run
Alice
Bartholomew

$ cargo test
running 3 tests
test tests::returns_self_name_when_longer ... ok
test tests::returns_other_when_longer ... ok
test tests::returns_other_when_equal_length ... ok

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

🪜 Step-by-Step 解説

📋 コピーfn pick_greeting<'a, 'b>(&'a self, other: &'b str) -> &'a str

📋 コピーfn pick_greeting<'a>(&'a self, other: &'a str) -> &'a str

📋 コピーfn pick_greeting_owned(&self, other: &str) -> String {
    if self.name.len() > other.len() { self.name.clone() } else { other.to_string() }
}

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

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

元のコード（fn pick_greeting(&self, other: &str) -> &str）をコンパイルすると、次のようなエラーが出ます。

読み方:

• error[E0623]: Day 010で見た E0106（ライフタイム注釈そのものが足りない）とは異なり、「省略ルールにより暗黙に決まったライフタイム同士が矛盾している」ことを示すエラーです
• this parameter and the return type are declared with different lifetimes: other（省略ルール1で割り当てられた無名のライフタイム）と、戻り値の型（省略ルール3で self 由来に固定されたライフタイム）が異なる、というメッセージです
• but data from `other` is returned here: 実際に返している値（other）の出どころを指し示しています。エラーメッセージが「シグネチャ上の約束」と「実装の中身」のズレを具体的に教えてくれています

修正方法: other にも明示的に self と同じライフタイムパラメータを与え、コンパイラの「暗黙の仮定」と実装の中身を一致させます。

📋 コピーfn pick_greeting<'a>(&'a self, other: &'a str) -> &'a str {
    if self.name.len() > other.len() { &self.name } else { other }
}

🌐 他言語との比較

C++で最も近い危険なパターンは「一時オブジェクトへの参照を返す」バグです。C++コンパイラは一部のケースで警告（-Wreturn-local-addr等）を出せますが、検出は完全ではなく、見逃すと未定義動作（ダングリング参照）に直結します。Rustでは省略ルール3によって「self 由来という前提」がシグネチャレベルで固定されるため、その前提と矛盾する実装は必ずコンパイルエラーとして止まります。C++が実行時（あるいは検出漏れ）に頼るのに対し、Rustは型システムのレベルでこの種のバグのクラス全体を排除しています。

🏆 実務での使いどころ

• APIの意図をシグネチャで伝える: pick_greeting<'a>(&'a self, other: &'a str) -> &'a str というシグネチャを見ただけで、呼び出し側は「戻り値は self か other のどちらか、または両方に由来しうる（self と同じかそれより短い寿命）」と読み取れます。ドキュメントを読まずともシグネチャから契約が伝わるのがRustの強みです
• リファクタリング時の安全網: メソッドの実装を変更して「self 由来だったはずの戻り値を、別の引数由来に変える」ようなリファクタリングをした際、省略ルール3が固定した戻り値のライフタイムと矛盾すればその場でコンパイルエラーになります。C++やGoであれば実行時までバグに気づけない変更が、Rustでは修正漏れとしてビルド段階で捕捉されます
• 借用中心のパーサ・トークナイザ設計: 文字列スライスを複数の引数から受け取り、条件によってどちらかを返すような関数（トークナイザの先読み処理など）は実務でも頻出パターンで、今回のような E0623 に遭遇しやすい代表例です

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: 今回の Greeter に3つ目の引数（例: other2: &str）を追加し、self.name / other / other2 のいずれかを返す設計にした場合、省略ルールはどう振る舞うか（ルール3はまだ成立するか）を自分で検証してみてください
• 次回予告: Day 012ではトレイト境界とwhere句を扱います。ジェネリクスに制約を課す書き方を学び、「どんな型でも受け付ける」設計から「特定の能力を持つ型だけを受け付ける」設計への発展を扱います

🎯 自己評価

自分の回答

気づき・メモ