Dart 3の網羅性チェック（Exhaustiveness Checking）を極限まで理解する：コンパイラ理論と静的防御のアーキテクチャ
Dart 3の導入によって、私たちの言語エコシステムは決定的なパラダイムシフトを経験した。とりわけ `switch` 式（Switch Expressions）とパターンマッチングの導入は、従来の命令型プログラミングの冗長性を排除し、代数的データ型（ADT）の恩恵を完全に享受できる環境をもたらした。
しかし、シニアエンジニアやフレームワークの設計者が直面する真の課題は、「新しい記法に慣れること」ではない。「将来の仕様変更（enumの追加やsealed階層の拡張）に際し、開発者の認知負荷やヒューマンエラーに依存せず、コンパイラによってシステム全体の破壊的変更を100%検出する防壁をどう構築するか」にある。
本稿では、Dartコンパイラ（CFA / Front End）が如何にして網羅性（Exhaustiveness）を判定しているのか、その理論的背景と、プロダクションコードにおける設計指針をランタイムの深部から紐解く。
—
1. コンパイラは「網羅性」をどう証明しているのか
多くのプログラマは、コンパイラの網羅性チェックを「すべてのケースが書かれているか数えているだけ」と誤解している。しかし、Dartのフロントエンド（FE）および型システムは、集合論における直和（Disjoint Union / Coproduct）とパターン空間の直交分解としてこれを処理している。
型の直和空間と空間充填（Space Filling）
`sealed class` や `enum` を定義した瞬間、それはDartの型システム内において「閉じた値の空間（Closed Domain）」を形成する。
例えば、以下の `sealed class` を考えてみよう。
sealed class NetworkState {}
class Idle extends NetworkState {}
class Loading extends NetworkState {}
class Success extends NetworkState {}
class Error extends NetworkState {}
この時、`NetworkState` 型が取り得る値の空間 $\mathcal{S}$ は、以下のように定義される。
$$\mathcal{S} = \{\text{Idle}\} \cup \{\text{Loading}\} \cup \{\text{Success}\} \cup \{\text{Error}\}$$
Dart 3の `switch` 式が評価される際、コンパイラのCFA（Control Flow Analysis）は、記述されたパターン群が作る空間 $\mathcal{P}$ が、元の空間 $\mathcal{S}$ を完全に覆っているか（$\mathcal{S} \subseteq \mathcal{P}$）を静的に検証する。
もし将来、誰かが `Maintenance` 状態を追加し忘れてコードベースを拡張した場合、空間 $\mathcal{S}’$ に新要素が加わるため、$\mathcal{S}’ \not\subseteq \mathcal{P}$ となり、コンパイラは即座にエラーを吐き出す。これが「コンパイル時安全性の本質」である。
—
2. 意図的な「網羅性破壊」と `default` / `_` のアンチパターン
多くの開発者が犯す最大のアーキテクチャ上の過ちは、`switch` 式や `switch` 文の末尾に安易に `_`（ワイルドカード）や `default` を置くことだ。
// ⚠️ 悪い設計：コンパイラの防壁を自ら無効化している
String handleState(NetworkState state) => switch (state) {
Idle() => ‘待機中’,
Loading() => ‘ロード中’,
Success() => ‘成功’,
Error() => ‘エラー’,
_ => ‘不明’, // これを書いた瞬間に網羅性チェックは死ぬ
};
上記のコードにおいて、将来 `Maintenance()` が追加されたとき、コンパイラは「`_` があるから安全だ」と判断し、エラーを出さない。結果として、ランタイムで新しい状態が `_` に吸い込まれ、「意図しないフォールスルー（あるいはデフォルト動作）」という名のサイレントバグが本番環境へデプロイされる。
チーフアーキテクチャの指針：ワイルドカードの封印
プロダクションコードの堅牢性を担保するためには、以下の鉄則をチームに課すべきである。
1. ドメインモデル（Enum / Sealed Class）の判定には `_` や `default` を一切使用しない。
2. 網羅性を強制し、コンパイラを私たちの「最強の静的解析フォロワー」として機能させる。
—
3. 実践：厳密な網羅性チェックを活かした設計パターン
では、実際のシステム設計において、どのようにこの機構を極限まで活かすべきか。ここでは、決済システムのトランザクション状態を例に、堅牢な実装を示す。
// 決済トランザクションの状態を表すSealed Hierarchy
sealed class TransactionResult {
const TransactionResult();
}
class Approved extends TransactionResult {
final String authorizationCode;
const Approved(this.authorizationCode);
}
class Declined extends TransactionResult {
final String reasonCode;
const Declined(this.reasonCode);
}
class RequiresAction extends TransactionResult {
final Uri authenticationUri;
const RequiresAction(this.authenticationUri);
}
// —————————————————————–
// アーキテクチャ上の極限設計：switch式による網羅的ディスパッチ
// —————————————————————–
String processTransaction(TransactionResult result) {
// ここに `default` や `_` は存在しない。
// 万が一、新しいサブクラス（例: FraudSuspected）が追加された場合、
// DartのAOT/JITコンパイラおよびアナライザーはビルドを即座に拒絶する。
return switch (result) {
Approved(authorizationCode: var code) =>
‘決済承認: AuthCode [$code]’,
Declined(reasonCode: var reason) =>
‘決済拒否: Reason [$reason]’,
RequiresAction(authenticationUri: var uri) =>
‘追加認証が必要です: 3DS Redirect -> $uri’,
};
}
コンパイル時保証のメカニズム
もしここで、ビジネス要件の変更により `class FraudSuspected extends TransactionResult {}` が追加されたとする。
開発者が `processTransaction` 関数内の修正を忘れた場合、Dartのフロントエンドコンパイラ（`analyzer` / `cfe`）は以下のエラーを出力し、成果物（Kernel Binary / dill）の生成を強制的に中断する。
Error: The type ‘TransactionResult’ is not exhaustively matched by the switch cases since it doesn’t match ‘FraudSuspected’.
この挙動こそが、CI/CDパイプラインにおいて「レビュー漏れ」や「仕様追従漏れ」を物理的に防ぐ究極の防壁となる。
—
4. パフォーマンスとランタイム最適化への影響
「ここまで厳密なパターンマッチングと網羅性チェックを行うことで、実行時パフォーマンス（JIT/AOT）にペナルティはあるのか？」という疑問を持つアーキテクトもいるだろう。
結論から言えば、ゼロ、あるいは従来のif-elseチェーンや従来のswitch文を凌駕する最適化が施される。
1. JIT / AOTにおけるジャンプテーブル（Jump Tables）の最適化:
Dart VMのコンパイラは、sealed classのサブタイプが静的に確定している（＝オープンではない）場合、C++の `std::variant` やRustの `enum` と同様に、効率的なディスパッチテーブル（またはインラインキャッシュ）を構築する。
2. 型ガードの排除:
網羅性が保証されているため、VMは冗長な型チェック（`is` チェックの連続）を排除し、オブジェクトのクラスID（Class ID）に基づく高速な分岐コードをネイティブマシン語にコンパイルする。
—
結びにかえて
言語仕様の進化は、単なる「コードの記述量を減らすための糖衣構文（Syntactic Sugar）」ではない。Dart 3のパターンマッチングと網羅性チェックは、「人間が忘れる生き物である」という前提に立ち、コンパイラという冷徹な論理エンジンにエラー検知を肩代わりさせるための最高峰のアーキテクチャツールである。
プロダクションコードから無駄な `default` を排除し、すべての状態遷移をコンパイラの監視下に置くこと。それこそが、大規模かつ長期運用されるDart/Flutterシステムを破綻から守る唯一にして絶対の道筋である。