第105章へようこそ。

今日のテーマは「型で状態を表現する」です。

第59章で型状態パターンを紹介しました。

ジェネリックパラメータのマーカー型で、状態を型に埋め込むパターン。

今日は、より広い視点で「型による保証」を考えます。

データ構造が、本来ありえない組み合わせを許してしまうことがある。

たとえば、ログインしていないのにメール確認済みになっている。

接続が切れているのにデータを送信しようとしている。

コードの上では表現できてしまうが、意味としては矛盾している。

こうした不正な状態を防ぐ方法は二つ。

一つは、実行時にチェックする方法。

if文で条件を調べ、不正ならエラーを返す。

もう一つは、コンパイル時に排除する方法。

不正な状態を型で表現できない構造にすれば、コンパイラがそれを弾く。

実行時チェックは、テストで検証する。テストに漏れがあれば、不正な状態はすり抜ける。

コンパイル時保証は、型の設計で検証する。設計に漏れがあれば、不正な状態はやはりすり抜ける。

Rustの型システムは、多くの不正な状態をコンパイル時に排除する力を持っています。

その力をどこまで使うか。これが設計判断です。

コンピュータ基礎学習へようこそ。

コンピュータは0と1で動いている。

これは誰もが聞いたことのある話です。

でも、0と1とは何でしょうか？

本当に「0」という数字や「1」という数字がどこかにあるのでしょうか？

今日は、この素朴な疑問に答えます。

第104章へようこそ。

今日のテーマは「抽象をどこまで広げるか」です。

ジェネリクスは強力です。

型パラメータを使えば、一つの関数があらゆる型に対応できる。

しかし「あらゆる型」が常に正しいわけではない。

境界が広すぎれば、使い手は何を渡せるのか分からない。

境界が狭すぎれば、不必要に型が制限されて使いにくい。

トレイト境界は、ジェネリクスの広がりに壁を立てる仕組みです。

その壁をどこに立てるかが、設計の判断になる。

第103章へようこそ。

今日のテーマは「閉じた世界と開いた世界」です。

Rustで「複数の種類を一つの型として扱いたい」とき、選択肢が二つあります。

enumで、すべてのバリアントを列挙する。

トレイトオブジェクトで、共通の能力だけを定義する。

どちらでも「異なる種類を統一的に扱う」ことはできます。

しかし、設計の意味がまったく異なる。

enumは、閉じた世界を作ります。

バリアントの一覧は定義の中に固定されている。後から追加するには定義を変更するしかない。

トレイトオブジェクトは、開いた世界を作ります。

トレイトを実装すれば、どんな型でも参加できる。後からいくらでも増やせる。

この「閉じている」か「開いている」かが、設計判断の出発点です。

第102章へようこそ。

今日のテーマは「トレイトの応用設計」です。

ここまで、トレイトシステムの仕組みを深掘りしてきました。

トレイトオブジェクト、ブランケット実装、オーファンルール、マーカートレイト、スーパートレイト、関連型と型パラメータ。

今日は、これらの仕組みを組み合わせた実践的な設計パターンを二つ学びます。

一つは、拡張トレイト。既存の型にメソッドを追加するパターン。

もう一つは、シールドトレイト。外部からの実装を封じるパターン。

どちらも、オーファンルールとトレイトシステムの特性を活かした設計技法です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 第1節：拡張トレイト ― 既存の型にメソッドを追加する

第101章へようこそ。

今日のテーマは「関連型と型パラメータの使い分け」です。

第12章で関連型を紹介しました。

IteratorトレイトのItem型。実装側が一つだけ決定する型。

そこでは、構文としての関連型を学びました。

今日は、設計判断としての関連型に踏み込みます。

トレイトに型を持たせる方法は二つあります。

関連型を使う方法と、型パラメータを使う方法。

Iteratorトレイトは関連型Itemを持っています。

nextメソッドの戻り値の中身が何の型かを、関連型Itemが決定する。

これを型パラメータで表現することもできたはずです。

Iteratorトレイト自体に型パラメータを持たせ、何の型を返すかを外から指定する方式。

どちらでも同じことが表現できるように見える。

しかし、意味がまったく違う。

この違いが、トレイト設計の核心に関わります。

第100章へようこそ。

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

第98章では、マーカートレイトを学びました。

メソッドを持たず、型の性質を宣言するトレイトでした。

今日は、トレイト同士の階層関係に踏み込みます。

Copyトレイトを実装するには、Cloneが必要でした。

CopyはCloneを前提としている。この関係を、スーパートレイトと呼びます。

CloneはCopyのスーパートレイト。

CopyはCloneのサブトレイト。

この階層関係は、トレイトの設計において重要な役割を果たします。

第99章へようこそ。

今日のテーマは「オーファンルール」です。

第96章では、ブランケット実装を学びました。

条件を満たすすべての型に、トレイトを一括実装する仕組みでした。

今日は、トレイト実装に課せられた制限を学びます。

Rustでは、他のクレートが定義したトレイトを、他のクレートが定義した型に実装することはできません。

たとえば、標準ライブラリのDisplayトレイトを、外部クレートのSomeTypeに対して、自分のクレートで実装することはできない。

これがオーファンルールです。

オーファンは「孤児」を意味します。

トレイトも型も自分のものでない実装は、親のいない孤児のようなもの。

どのクレートが責任を持つのか分からない。だから禁止される。

第98章へようこそ。

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

第94章でSizedを学びました。第97章でSendとSyncを学びました。これらには共通点がある。メソッドが一つもない。

Iteratorにはnextがある。Displayにはfmtがある。Dropにはdropがある。

しかしSized、Send、Syncにはメソッドがない。

メソッドがないのに、何のために存在するのか。

型の性質をコンパイラに伝えるためです。「この型はこういう性質を持つ」と宣言する。コンパイラはこの宣言を使って、安全でないコードを拒否する。

こうしたトレイトを、マーカートレイトと呼びます。

今日は、Sized、Send、Syncに続くマーカートレイトとして、CopyとUnpinを掘り下げ、マーカートレイト全体の仕組みを俯瞰します。

第97章へようこそ。

今日のテーマは「所有権がスレッド安全を生む」です。

第42章でSendとSyncに触れました。そこではスレッドの安全性という文脈の中で、名前と基本的な意味を紹介しました。

今日は、SendとSyncをトレイトとして深く見ます。

なぜメソッドが一つもないのか。なぜコンパイラが自動的に実装するのか。そしてなぜ所有権のルールだけでスレッド安全が実現されるのか。

Rustの並行性の安全保証は、ランタイムの仕組みではありません。

SendとSyncという二つのマーカートレイトと、所有権の規則の組み合わせで、コンパイル時に実現されている。