Day 010 — ライフタイム省略規則 — 明示が不要になる3つのルール

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

Day 009では、longest関数がなぜ<'a>を明示しないとコンパイルできないのかを見ました。一方でannounce_and_return_part(&self, announcement: &str) -> &strはライフタイム注釈なしでコンパイルが通りました。「なぜある関数は注釈が要り、別の関数は要らないのか」——この境界線を人間の勘ではなくコンパイラが機械的に判定するための固定ルールが、今日学ぶライフタイム省略規則（lifetime elision rules）です。

省略規則は「推測」ではなく「決定的なアルゴリズム」

重要な前提として、ライフタイム省略は曖昧さを許容する賢い推論ではありません。コンパイラは以下の3つのルールをこの順番で機械的に適用し、すべてのライフタイムを解決できればコンパイルを通し、解決できなければE0106エラーを出して人間に明示を要求します。ルールに当てはまらないケースで「たぶんこっちだろう」と推測することは一切ありません。

📋 コピーfn foo(x: &str, y: &str)
// コンパイラ内部ではこう解釈される:
fn foo<'a, 'b>(x: &'a str, y: &'b str)

引数が何個あっても、省略された&にはそれぞれ独立した名前のないライフタイムが割り当てられます。

📋 コピーfn first_word(s: &str) -> &str
// コンパイラ内部ではこう解釈される:
fn first_word<'a>(s: &'a str) -> &'a str

引数の参照が1つしかない場合、戻り値の参照が「どの引数由来か」に曖昧さがないため、そのまま流用できます。

📋 コピーimpl<'a> ImportantExcerpt<'a> {
    fn announce_and_return_part(&self, announcement: &str) -> &str
    // コンパイラ内部ではこう解釈される:
    fn announce_and_return_part<'b>(&'a self, announcement: &'b str) -> &'a str
}

引数は&selfとannouncement: &strの2つですが、「メソッドが返す参照は大抵の場合selfが持っているデータ由来だろう」という設計上の経験則をルールとして固定化し、この場合だけ特別に「自己（self）優先」で解決します。

3つのルールすべてを適用しても解決できない場合

Day 009のlongest(x: &str, y: &str) -> &strはルール1で'a・'bという別々のライフタイムが割り当てられますが、入力ライフタイム位置が2つあるためルール2は不適用、&selfもないためルール3も不適用です。結果、戻り値の&strのライフタイムが未解決のまま残り、コンパイラはE0106: missing lifetime specifierを出して人間に明示を要求します。

📝 問題

1. 概念理解課題: 3つのライフタイム省略ルールを自分の言葉で説明してください。また、なぜこれらが「曖昧な状況での推測」ではなく「決定的なアルゴリズム」だと言えるのか、理由を添えて説明してください
2. 判定課題: 以下の4つの関数・メソッドシグネチャそれぞれについて、(a) ライフタイム注釈なしでコンパイルが通るか、(b) 通るならどの規則（ルール1〜3）が適用されて解決するか、(c) 通らないなら理由、を答えてください

   📋 コピーfn print_str(s: &str) {}
   
   fn first_word(s: &str) -> &str {
       s.split_whitespace().next().unwrap_or("")
   }
   
   fn longest(x: &str, y: &str) -> &str {
       if x.len() > y.len() { x } else { y }
   }
   
   struct Parser;
   impl Parser {
       fn peek<'b>(&self, s: &'b str) -> &str {
           s
       }
   }

3. デバッグ予測課題: 以下のcombine関数はコンパイルエラーになります。何というエラーコードが出るか、そして3つの省略ルールをそれぞれ順番に適用してみて「なぜどのルールも解決に使えないのか」を説明してください

   📋 コピーfn combine(a: &str, b: &str, c: &str) -> &str {
       if a.len() >= b.len() && a.len() >= c.len() { a }
       else if b.len() >= c.len() { b }
       else { c }
   }

4. 実装課題: Day 009で作ったImportantExcerpt<'a>構造体（フィールドpart: &'a str）に、ライフタイム注釈を一切書かずに（省略ルール3に任せて）以下の2つのメソッドを追加してください
   • fn part_len(&self) -> usize — self.partの文字数（バイト数）を返す
   • fn first_word(&self) -> &str — self.partの最初の単語（空白区切り）を返す
   両方ともコンパイルが通ることを、テストで確認してください

🔍 ヒント（段階的開示）

📋 コピーstruct ImportantExcerpt<'a> {
    part: &'a str,
}

impl<'a> ImportantExcerpt<'a> {
    fn new(part: &'a str) -> ImportantExcerpt<'a> {
        ImportantExcerpt { part }
    }

    // 追加するメソッドはここに書く。ライフタイム注釈は不要（省略規則が解決する）
    fn part_len(&self) -> usize {
        self.part.len()
    }

    fn first_word(&self) -> &str {
        self.part.split_whitespace().next().unwrap_or("")
    }
}

✅ 模範解答

📋 コピーstruct ImportantExcerpt<'a> {
    part: &'a str,
}

impl<'a> ImportantExcerpt<'a> {
    fn new(part: &'a str) -> ImportantExcerpt<'a> {
        ImportantExcerpt { part }
    }

    // 省略ルール3: &self があるので、戻り値がもし参照を含んでいれば self のライフタイムに
    // 紐づけられる。ただしこのメソッドの戻り値は usize（借用ではない）なので、
    // そもそもライフタイム解決の対象にすらならない。
    fn part_len(&self) -> usize {
        self.part.len()
    }

    // 省略ルール3が実際に働くケース。引数は &self のみ（ルール1で 'a が割り当て済み）。
    // 入力ライフタイム位置は1つなのでルール2でも解決できるし、&self があるのでルール3でも
    // 同じ結論（self 由来）に至る。コンパイラ内部の解釈は次と等価:
    //   fn first_word<'b>(&'b self) -> &'b str
    fn first_word(&self) -> &str {
        self.part.split_whitespace().next().unwrap_or("")
    }
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().unwrap();
    let excerpt = ImportantExcerpt::new(first_sentence);

    println!("part_len = {}", excerpt.part_len());
    println!("first_word = {}", excerpt.first_word());
}

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

    #[test]
    fn test_part_len() {
        let excerpt = ImportantExcerpt::new("Call me Ishmael");
        assert_eq!(excerpt.part_len(), 16);
    }

    #[test]
    fn test_first_word() {
        let excerpt = ImportantExcerpt::new("Call me Ishmael");
        assert_eq!(excerpt.first_word(), "Call");
    }

    #[test]
    fn test_first_word_single_word() {
        let excerpt = ImportantExcerpt::new("Ishmael");
        assert_eq!(excerpt.first_word(), "Ishmael");
    }
}

$ cargo run
part_len = 16
first_word = Call

$ cargo test
running 3 tests
test tests::test_part_len ... ok
test tests::test_first_word ... ok
test tests::test_first_word_single_word ... ok

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

🪜 Step-by-Step 解説

📋 コピーfn print_str(s: &str) {}

📋 コピーfn first_word(s: &str) -> &str { ... }

📋 コピーfn longest(x: &str, y: &str) -> &str { ... }

📋 コピーimpl Parser {
    fn peek<'b>(&self, s: &'b str) -> &str { s }
}

📋 コピーfn combine(a: &str, b: &str, c: &str) -> &str

📋 コピーfn first_word(&self) -> &str {
    self.part.split_whitespace().next().unwrap_or("")
}

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

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

問題3のcombine（ライフタイム注釈なし、3引数）です。

📋 コピーfn combine(a: &str, b: &str, c: &str) -> &str {
    if a.len() >= b.len() && a.len() >= c.len() { a }
    else if b.len() >= c.len() { b }
    else { c }
}

読み方:

• error[E0106]: Day 009と同じエラーコードです。省略規則の3つとも解決に使えなかったことを示しています
• expected named lifetime parameter: 戻り値の&strにライフタイムパラメータが必要だが、シグネチャに書かれていないという意味です
• helpメッセージの「borrowed from a, b, or c」の部分が、引数が2つのとき（x, yのみ）より選択肢が1つ増えている点に注目してください——引数が増えても、コンパイラのエラーメッセージの構造自体は同じです

修正方法: 実際に返り得る全ての引数（a・b・cすべて）に同じライフタイムパラメータ'aを付ける必要があります。

📋 コピーfn combine<'a>(a: &'a str, b: &'a str, c: &'a str) -> &'a str {
    if a.len() >= b.len() && a.len() >= c.len() { a }
    else if b.len() >= c.len() { b }
    else { c }
}

🌐 他言語との比較

省略規則に最も近い概念を持つ言語はRust以外にほぼ存在しません。GC言語（Go/Java/TypeScript）では参照の生存期間をランタイムが管理するため、そもそも「ライフタイムを省略できるかどうか」という問いが発生しません。C++のテンプレート引数推論やautoは「型」を推論する仕組みであり、「参照同士の生存期間の関係」を推論する仕組みではないため、目的も適用範囲も異なります。

🏆 実務での使いどころ

• APIレビューでの「なぜここだけ<'a>が必要なのか」判断: 大規模なコードベースでは、大多数の関数がライフタイム注釈なしで書かれています。レビュー中に明示的な<'a>が付いた関数を見かけたら、それは「3つの省略ルールでは解決できない、意図的な関係の明示」であるサインとして読めるようになります
• ライブラリ設計時のシグネチャ簡潔化: &selfを含むgetter系メソッドの大半は省略規則（ルール3）のおかげで注釈不要になります。逆に、複数の借用を受け取って1つを返すような関数（combineのような設計）では、意図的にライフタイムを明示しないと呼び出し側が混乱するため、設計段階で「この関数は省略規則で解決できるか」をチェックする習慣が役立ちます
• clippyやコンパイラの提案の理解: rustcが「lifetime elision」に関する警告やヒントを出す場面（例: needless_lifetimes）で、省略規則の仕組みを理解していれば、提案されたコードが安全かどうかを自分で判断できます

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: Parser::peekのように「省略ルールの機械的な結論」と「関数の中身が実際にやっていること」がズレるケースを自分でもう1つ作り、実際にcargo buildしてどんなエラー（または警告）が出るか確認してみてください
• 次回予告: Day 011ではトレイト境界とwhere句を扱います。ジェネリクスに制約を課す書き方を学び、「どんな型でも受け付ける」設計から「特定の能力を持つ型だけを受け付ける」設計への発展を扱います

🎯 自己評価

自分の回答

気づき・メモ