第15章へようこそ。

今日のテーマは「ライフタイム省略と'static」です。

前の2章でライフタイム注釈の書き方を学びました。

しかし、実際のRustコードを見ると、ライフタイム注釈が書かれている関数は意外と少ない。

参照を受け取って参照を返す関数でも、注釈なしで書かれていることが多い。

これは、コンパイラが自動的に注釈を補っているからです。

この補完の仕組みをライフタイム省略規則と呼ぶ。

もう1つ、今日扱うのは'staticという特別なライフタイム。

プログラムの実行中、ずっと有効であり続ける参照のライフタイムです。

この2つを理解すれば、ライフタイム編の基礎が完成します。

第14章へようこそ。

今日のテーマは「関数と構造体のライフタイム」です。

前章でライフタイムの概念を学びました。

参照には有効期間があり、それが型システムの一部として扱われる。

今日は、ライフタイム注釈を実際に書く場面を見ていきます。

関数が参照を受け取って参照を返すとき。

構造体が参照をフィールドに持つとき。

メソッドを定義するとき。

それぞれで注釈がどう書かれ、何を意味するかを見ていきます。

第13章へようこそ。

今日のテーマは「ライフタイム」です。

第1章で所有権と借用を学びました。

値の所有者は常に1つ。参照を作ることで値を借りられる。

借りている間、元の値は動かせない。

しかし、第1章では触れなかった問いがあります。

参照はいつまで有効なのか。

参照が指している先の値が消えたら、参照はどうなるのか。

この問いに答える仕組みが、ライフタイムです。

ライフタイムは、参照の有効期間を型システムの一部として扱う仕組み。

Rustの安全性保証の中核をなす概念です。

第12章へようこそ。

今日のテーマは「関連型」です。

第4章でイテレータを学んだとき、Itemという言葉が出てきました。

イテレータが返す要素の型。整数のイテレータなら整数。文字列のイテレータなら文字列。

このItemは、Iteratorトレイトの中で定義された型です。

トレイトの中に型が定義されている。これが関連型。

関連型は、第10章の型パラメータと似た役割を持つように見える。

どちらも「後から決まる型」を表現する。

しかし、型パラメータと関連型には構造的な違いがあります。

なぜRustは両方を用意したのか。どう使い分けるのか。

今日はこの違いを見ていきます。

第11章へようこそ。

今日のテーマは「トレイト境界」です。

前章で、制約のない型パラメータTにはほとんど何もできないと話しました。

Tがどんな型かわからない以上、比較も表示も複製もできない。

第8章でトレイトを学びました。

トレイトは「このメソッド群を持つこと」という契約を定義する仕組みでした。

トレイト境界は、この2つを結びつけます。

「Tはこのトレイトを実装している」という条件を型パラメータに付ける。

ジェネリクスとトレイトの合流点です。

第10章へようこそ。

今日のテーマは「ジェネリクス」です。

ここまでの章で、すでにジェネリクスに何度も出会っています。

第2章のOption型。第3章のResult型。第4章のイテレータが返すVec。

これらはすべて、型パラメータを持つジェネリックな型です。

しかし、「型パラメータを持つ」とはどういうことか。

なぜ型をパラメータにする必要があるのか。

コンパイラはジェネリックなコードをどう処理するのか。

今日はこの仕組みを正面から見ていきます。

第9章へようこそ。

今日のテーマは「エラー型の設計」です。

第3章でResult型を学びました。

関数が失敗しうるとき、戻り値をResult型にする。Okに成功時のあたいが入り、Errにエラー情報が入る。

?演算子で、エラーを呼び出し元に伝播できる。

しかし、第3章では触れなかったことがあります。

Errの中に入れるエラー型を、どう設計するのか。

ファイルの読み込みは入出力エラーを返す。文字列のパースはパースエラーを返す。

1つの関数の中で、異なる種類のエラーが発生しうるとき、戻り値のエラー型は何にするのか。

エラーを受け取った側は、どうやって失敗の種類を区別するのか。

第8章でトレイトを学んだことで、この問題に正面から向き合えます。

Rustのエラー処理は、トレイトの仕組みの上に構築されている。

第8章へようこそ。

今日のテーマは「トレイト」です。

第6章で構造体とenumを扱いました。

構造体はデータの形を定義し、implブロックでメソッドを付けた。

しかし、あのメソッドは特定の構造体にしか使えない。

構造体Aに定義したメソッドは、構造体Bには使えない。

ここで疑問が生まれます。

異なる型が同じ操作を持つことを、どう表現するのか。

たとえば、文字列として表示するという操作は、整数にも浮動小数点数にも構造体にも欲しい。

しかし、それぞれの型で表示のやり方は違う。

整数なら数字の列に変換する。浮動小数点数なら小数点を含む形に変換する。構造体ならフィールドを順に並べる。

操作の名前は同じだが、実装は型ごとに違う。

この「共通の操作名」と「型ごとの実装」を分離する仕組みが、トレイトです。

トレイトはRustの型システムの中核にある概念です。

今日はトレイトが何を解決し、どう機能するかを、構造から見ていきます。

第7章へようこそ。

今日のテーマはパターンマッチです。

第2章のOptionでmatchを使ってSomeとNoneに分岐しました。

第3章のResultでもmatchでOkとErrに分岐しました。

第6章のenumでも、バリアントの判定にmatchを使うと説明しました。

これまで道具として使ってきたmatchの背後には、「パターン」という仕組みがあります。

パターンとは、あたいの構造を記述する式です。

matchは値とパターンを照合し、一致したパターンに対応する処理を実行する。

今日はこのパターンという仕組みを体系的に扱います。

パターンが使える場所はmatch式だけではない。

let束縛、関数の引数、forループにもパターンが現れる。

パターンはRustの構文全体に組み込まれた仕組みです。

第6章へようこそ。

今日のテーマはstructとenum、つまり構造体と列挙型、です。

ここまでの章で、i32やString、boolといった型を使ってきました。

これらはRustが最初から用意している型です。

しかし実際のプログラムでは、これだけでは足りない。

ユーザーの名前と年齢とメールアドレスを1つにまとめて扱いたい。

処理の結果が「成功」「タイムアウト」「認証失敗」のどれかであることを型で表したい。

structとenumは、プログラマが自分で型を定義するための仕組みです。

structは「これらのデータをすべて持つ」型を作る。

enumは「これらの可能性のうちどれか1つ」を表す型を作る。

この「すべて」と「どれか1つ」の区別が、今日の章の核心です。