Dart 3 switch式の網羅性チェック：コンパイラ理論とランタイム最適化の極限
Dart 3における最大のパラダイムシフトは、言語仕様へのパターンマッチングの統合である。特に`switch`文から`switch`「式（Expression）」への進化は、単なる糖衣構文の追加ではない。CFA（Control Flow Analysis：制御フロー解析）と型システムの中核に踏み込み、静的解析の精度を極限まで高めたコンパイラ設計の結晶である。
本稿では、Dartのコンパイラ（Common Front End: CFE）がどのように網羅性（Exhaustiveness）を判定しているのか、その数学的・アルゴリズム的メカニズムを解き明かす。さらに、実務上の要請から網羅性チェックを「あえて制御・回避」しなければならないシチュエーションにおいて、型安全性を崩壊させずにコンパイラを納得させるためのアーキテクチャパターンを提示する。
—
1. コンパイラは「網羅性」をどう証明しているのか？
多くのプログラマは、`switch`式の網羅性チェックを「すべてのケースが列挙されているかコンパイラが目で確認している」程度に捉えている。しかし、DartのCFAおよび静的型チェッカーは、集合論の直和（Disjoint Union / Sum Types）と部分型（Subtyping）の格子構造に基づいてこれを証明している。
空間の分割と型の直和
有限の型空間 $S$ において、入力値の型が $T$ であるとき、`switch`式は $T$ の値域を交差しない部分空間 $P_1, P_2, \dots, P_n$ に分割（Partition）する作業である。
コンパイラ（CFE）は、以下のステップで網羅性を検証する。
1. 静的型の確定: 入力式（Target Expression）の静的型を導出する。これが網羅性検証の「全体集合（Universe）」となる。
2. パターン空間の正規化: 各`case`パターンを、型と値の制約の組へと分解・正規化する。
3. 到達可能性と残余（Remainder）の計算:
全体集合 $U$ から、各パターンがカバーする空間を順次減算していく。もし残余集合 $R = U \setminus \bigcup_{i=1}^n P_i$ が空集合 $\emptyset$ でない場合、コンパイラは網羅性違反エラー（Compile-Time Error）を発生させる。
sealed class NetworkResponse {}
class Success extends NetworkResponse {
final String data;
Success(this.data);
}
class Error extends NetworkResponse {
final int code;
Error(this.code);
}
String handleResponse(NetworkResponse response) {
// コンパイラは NetworkResponse の空間が
// Success と Error の直和であることを認識している
return switch (response) {
Success(data: var d) => ‘Data: $d’,
Error(code: 404) => ‘Not Found’,
// ここで Error(code: 404 以外) が残るため、コンパイルエラーになる
};
}
上記のコードでコンパイルエラーになるのは、`Error`クラスのうち `code != 404` の部分空間が残余として取り残されているからだ。CFEは、この「取り残された空間」を正確に検出し、開発者に突きつけている。
—
2. 網羅性チェックの裏にあるCFEの最適化とジャンプテーブル
Dart VM（AOT/JIT）の実行時性能において、`switch`式は単なる`if-else`の連続にコンパイルされるとは限らない。CFAが網羅性を完全に保証しているという事実そのものが、コード生成フェーズにおいて強力な最適化の根拠となる。
1. 密なジャンプテーブル（Jump Tables）の生成
ケースの値が連続した整数や列挙型（Enum）であり、かつ網羅されている場合、バックエンド（Kernel to AST / Assembly）は、O(1)の計算量で分岐するためのインデックス付きジャンプテーブルを生成する。
2. シールドクラス（Sealed Classes）のディスパッチ最適化
`sealed`修飾子が付与されたクラス階層に対する網羅的な`switch`式は、実行時に動的な型チェック（`is`判定の連鎖）の順序を最適化、あるいは仮想メソッドテーブル（vtable）のオフセット参照へとコンパイル時に直結させることができる。開発者が「他にケースがない」と保証（網羅）しているため、ランタイムはデフォルトケース（`default`）のフォールバック処理や例外送出用のガードコードを省き、コードサイズを削減できる。
—
3. 「意図的な網羅性回避」の安全な設計パターン
ビジネスロジックの肥大化や、外部APIの変更、あるいはテスト目的などで、「あえて網羅性チェックを迂回したい」というケースに直面することがある。例えば、将来追加されるかもしれない未知のステートを無視したい場合や、パフォーマンスクリティカルなパスで特定の値だけをハンドリングしたい場合だ。
しかし、安易に `default` や `_`（ワイルドカード）を置くことは、将来の仕様変更時に「新しいステートのハンドリング漏れ」というサイレントバグを産むリスク（脆弱性）を抱えることになる。
これを防ぎつつ、コンパイラを制御するための高度なアーキテクチャパターンを提示する。
パターンA: ワイルドカードパターンによる明示的フォールバックとログ・アサーション
Dart 3のワイルドカードパターン（`_`）を使用することで、残余空間を強制的に吸収しつつ、実行時ガードを入れるアプローチ。
enum DatabaseDriver { postgres, mysql, sqlite, mongodb }
String getConnectionString(DatabaseDriver driver) {
return switch (driver) {
DatabaseDriver.postgres => ‘pg://…’,
DatabaseDriver.mysql => ‘mysql://…’,
// mongodb や、将来追加されるかもしれない未来のドライバをまとめて処理
_ => _handleUnsupportedDriver(driver),
};
}
String _handleUnsupportedDriver(DatabaseDriver driver) {
// 開発環境では即座に検知し、本番環境ではフォールバックする防壁
assert(false, ‘Unsupported database driver: $driver’);
return ‘default://fallback’;
}
アーキテクチャ的考察:
この手法の美しさは、静的解析の網羅性エラーをクリアしながら、実行時における「未知の入力」に対する安全網（Fail-Safe）を構築している点にある。
パターンB: 拡張性を持たせた「Extensible Union」とアノテーションによる制御
もし完全に特定のケースだけをマッチさせ、残りはコンパイラにエラーを出させたくない（しかし安全性を担保したい）場合、意図的に「その他」を表現するサブタイプを設計階層に組み込む。
sealed class AppState {}
class Loading extends AppState {}
class Loaded extends AppState {}
// 将来の拡張用、または意図的に無視するためのセーフティネットクラス
class UnknownState extends AppState {
final AppState original;
UnknownState(this.original);
}
このアプローチを取ることで、`switch`式側では `Loading` と `Loaded` だけを書き、残りを `UnknownState` やワイルドカードで受けるという構造化が可能になる。これにより、コンパイラの静的チェック機能をバイパスするのではなく、「型システムの内側で制御する」というクリーンなアーキテクチャを維持できる。
—
4. チーフアーキテクトからの提言：コンパイラを敵に回すな、味方に付けろ
多くのプログラマは、コンパイラの警告やエラーを「開発を邪魔する障害物」と捉えがちである。しかし、Dart 3の網羅性チェックは、あなたの脳のメモリ消費量を肩代わりし、将来のコード変更による致命的なランタイムクラッシュを未然に防ぐための「最強の静的防壁」である。
`default`やワイルドカード `_` を安易に乱用することは、この防壁に自ら穴を開ける行為に他ならない。どうしても網羅性を制御しなければならない極限の状況下であっても、本稿で示したような、型システムとアサーションを組み合わせた厳密な境界防衛（Boundary Defense）を構築すべきだ。
ランタイムの挙動、メモリレイアウト、そしてコンパイラの思考プロセスまでを脳内に同期させた者だけが、真に堅牢で高速なDartアプリケーションをエンジニアリングできる。言語の仕様に寄りかかるのではなく、言語の深淵を支配せよ。