Dart 3 網羅性チェックの深層：コンパイラが型システムを「強制」するメカニズム
Dart 3の導入によって、私たちのコードベースは静的解析の厳密性と表現力の面でパラダイムシフトを経験した。その中でも、最も静かに、しかし最も劇的にランタイムの安全性と保守性を底上げしているのが パターンマッチングにおける網羅性チェック（Exhaustiveness Checking） である。
ネット上の入門記事では「`sealed` クラスを使えば、すべてのサブクラスを `switch` で網羅しないとコンパイルエラーになるので安全です」といった表層的な説明に終始しがちだ。しかし、シニアエンジニアや基盤レイヤを設計する者にとって重要なのは、この保証が コンパイラのフロントエンド（CFE: Common Front End）とCFA（Control Flow Analysis）によって如何にして機械的・数学的に担保されているか という点に他ならない。
本稿では、Dartのコンパイルパイプラインがどのように型空間を解釈し、網羅性を証明しているのか、その低レイヤのメカニズムとメモリ効率への帰結を解き明かす。
—
1. コンパイラが「すべて」を知る方法：CFEとCFAの内部挙動
Dartの `switch` 式（あるいは文）における網羅性チェックは、単なるテキストマッチングや名前のリスト照合ではない。CFE（Common Front End）がソースコードを抽象構文木（AST）に変換し、静的型システムの中で 直和型（Algebraic Data Types: ADTs）の集合論的縮約（Reduction） を計算している。
型空間の「直和」と静的包含関係
`sealed` 修飾子が付与されたクラスや、`enum` は、その閉じた（Closed）型階層をコンパイラに宣言する行為である。
sealed class NetworkResult
class Success
final T data;
Success(this.data);
}
class Failure
final Object error;
Failure(this.error);
}
class Loading
この時、`NetworkResult
コンパイラは `switch (result)` に遭遇すると、以下のステップで網羅性を検証する。
1. 入力型の抽出: 入力値の静的型（例: `NetworkResult
2. パターン空間の分解: `switch` の各 `case` 節がカバーする型と値の空間を抽出する。
3. 集合の差分演算（Set Difference）: 入力型の全集合から、各 `case` がカバーする空間を順次引き去っていく（Subtyping Reduction）。
4. 空集合の証明: 最終的な残余空間（Remainder）が 空集合（Bottom Type `Never` に相当する領域） であることを証明できれば網羅と判定される。もし残余集合が存在すれば、コンパイルエラーとしてその未処理の型を開発者に突きつける。
このプロセスは完全にコンパイル時（AOT/JITのビルドフェーズ）に完結しており、実行時（Dart VM）のオーバーヘッドは一切発生しない。型システムが静的に整合性を担保するため、ランタイムは無駄な `NoSuchMethodError` や `TypeError` を防ぐための防衛的コードを排除できるのだ。
—
2. 実行時最適化とジャンプテーブル（Jump Table）の生成
網羅性チェックが保証されているという事実が、Dart VMのバックエンド（Kernel to AST / AOTコンパイラ）にどのような恩恵をもたらすか。それは 機械語レベルでの最適化の極限追求 である。
例えば、単純な `enum` に対する網羅的な `switch` 式は、コンパイラによって O(1) のジャンプテーブル（あるいはディスパッチテーブル） にコンパイルされる。
enum ExecutionState { idle, running, paused, terminated }
String getDispatchCode(ExecutionState state) => switch (state) {
ExecutionState.idle => ‘0x00’,
ExecutionState.running => ‘0x01’,
ExecutionState.paused => ‘0x02’,
ExecutionState.terminated => ‘0xFF’,
};
開発者がすべてのケースを網羅している（Exhaustiveである）ことが静的に証明されているため、コンパイラは `default` 節やフォールスルー（Fall-through）を考慮した分岐ツリーを生成する必要がない。これにより、CPUの分岐予測（Branch Prediction）のミスヒット率を最小化し、パイプラインハザードを回避する極めて効率的なアセンブリコードが生成される。
もし網羅性チェックがなければ、コンパイラは「未知の値が入力された場合の安全策（デッドコードや例外スロー）」のパスを維持しなければならず、コードサイズ（Textセグメント）の肥大化とキャッシュ効率の低下を招く。
—
3. 実践：複雑なパターンマッチングと網羅性の破綻を防ぐ設計
実務のアーキテクチャにおいて、網羅性チェックは単なる「エラー回避の儀式」ではない。ドメインロジックの変更漏れをコンパイラに検知させるための 最強の静的アサーション である。
以下のコードは、型パラメータを持つ複雑な階層構造において、網羅性チェックがどのように機能するかを示した実践的なモジュールである。
sealed class DatabaseOperation
class Insert
final T record;
Insert(this.record);
}
class Update
final String id;
final T newRecord;
Update(this.id, this.newRecord);
}
class Delete
final String id;
Delete(this.id);
}
/// コンパイラが網羅性を強制するトランザクションレイヤー
String executeOperation
return switch (op) {
// Insertパターンの分解とガード節の併用
Insert(record: var r) when r != null => ‘INSERT: $r’,
Insert() => throw ArgumentError(‘Record cannot be null for insertion’),
// Updateパターン
Update(id: var id, :var newRecord) => ‘UPDATE [$id]: $newRecord’,
// Deleteパターン
Delete(id: var id) => ‘DELETE [$id]’,
// 【極限の知見】
// ここで仮に Delete クラスの処理をコメントアウトすると、
// CFEは残余空間に Delete
// “The type ‘Delete
};
}
void main() {
DatabaseOperation
// 実行時イベントループへ渡る前のプレフライト検証
print(executeOperation(op));
// 実行結果: INSERT: Dart 3 Core
}
このコードのアーキテクチャ的意味
1. オブジェクトの分解（Destructuring）: パターンマッチングは単なる型判定にとどまらず、内部プロパティ（`id`, `record`）を直接バインドする。
2. ガード節（Guards）との共存: `when` 句を用いた条件付きマッチングが存在する場合でも、コンパイラはベースの型空間が網羅されているかを追跡する（※ガード節自体は実行時評価のため、型システムの網羅性証明とは別個に処理される点に注意せよ）。
3. 将来の拡張性（Future-proof Architecture）: 将来的に `DatabaseOperation` に `BatchUpdate` などの新しいサブクラスを追加した場合、この `switch` 式を使用しているすべての箇所で 即座にコンパイルエラーが発生 する。これにより、開発者はアーキテクチャの変更漏れを物理的に見落とせなくなる。
—
4. チーフアーキテクトからの提言：網羅性を「ハック」しない
未熟なコードベースでは、網羅性チェックの厳格さから逃れるために以下のようなアンチパターンが見受けられる。
- `switch (op)` の最後に無意味な `_ => throw …` や `_ => 0` を記述して網羅性チェックをバイパスする。
- 不必要な `default` 節を常駐させる。
これは Dart 3 がもたらす最大の恩恵である 「型安全の自動追従」を自ら放棄する行為 に他ならない。新しいサブクラスを追加した際、コンパイラがエラーによって「ここを修正しろ」と教えてくれるシグナルこそが、大規模かつ堅牢なシステムを維持する最大の防壁なのである。
Dartのランタイムとコンパイラの内部構造を理解した上で、この網羅性チェックをコードベースの隅々にまで行き渡らせよ。それこそが、予測不能な実行時エラーを完全に駆逐する唯一無二のエンジニアリングである。