Dart 3 パターンマッチングと Never 型の融合：コンパイラを欺く「論理的矛盾」を型で封じ込める極限の防壁
Dart 3 で導入されたパターンマッチングと網羅性チェック（Exhaustiveness Checking）は、フロントエンド開発の記述力を飛躍的に向上させた。しかし、この強力な機能の真価は、単なるボイラープレートの削減ではない。
C++の `std::unreachable()` や Rust の `unreachable!()` に相当する概念を、Dart の静的型システムと `Never` 型を用いていかに美しく、かつランタイムの安全性を損なわずに実装するか。今回は、Dart VMのコンパイルパイプラインとフロー解析（Flow Analysis）の挙動に踏み込みながら、到達不能コードをコンパイル時に完全に保証する設計手法を解剖する。
—
1. Dart コンパイラにおける網羅性チェックのメカニズム
Dart のCFA（Control Flow Analysis）およびCFA（Control Flow Graph）ビルダーは、`switch` 式がすべての可能な型空間をカバーしているかを静的に検証する。
例えば、以下のような直和型（Algebraic Data Types）を模したシールドクラス（sealed class）を考える。
sealed class NetworkState {}
class Loading extends NetworkState {}
class Success extends NetworkState {}
class Error extends NetworkState {}
この `NetworkState` に対する `switch` 式を書くとき、すべてのサブタイプを列挙しなければ、Dart コンパイラ（CFE: Common Front End）はエラーを吐く。
String handleState(NetworkState state) {
return switch (state) {
Loading() => ‘Loading…’,
Success() => ‘Success!’,
Error() => ‘Error occurred.’,
// ここでどれか一つでも欠けるとコンパイルエラーになる
};
}
では、将来的に `Maintenance` という新しいサブタイプが追加されたとき、開発者がこの `switch` 式への追記を忘れたらどうなるか？ 網羅性チェックがなければ、ランタイムエラー（`TypeError` や `StateError`）が本番環境で爆発することになる。これをコンパイル時に検知するのが Dart 3 の網羅性チェックの役割だ。
—
2. `Never` 型の正体：ボトム型（Bottom Type）の厳密な定義
Dart における `Never` 型は、「いかなる値も持たない値の型」、すなわち型理論におけるボトム型（$\bot$）である。
ランタイムにおいて、`Never` 型の式が評価されることは物理的にあり得ない。例外を投げる関数（`throw`）や、無限ループに陥る関数の戻り値型として暗黙的・明示的に利用される。
Never throwFatalError(String message) {
throw StateError(message);
}
この `Never` 型の性質を `switch` 式の網羅性チェックと組み合わせることで、「ここに到達したらコンパイルエラー、あるいは論理的に絶対に到達しない」という証明を型システムに強制させることができる。
—
3. 実装パターン：`default` ケースにおける `Never` の防壁
現実の大規模アプリケーションでは、ドメインモデルの拡張や、サードパーティライブラリのバージョンアップによって、予期せぬサブタイプが流入するリスクがある。あるいは、網羅しているはずだが型システムがそれを追跡しきれない複雑なケースもある。
ここで、`switch` 式の最後に `_ =>`（デフォルトケース）を置き、そこに `Never` 型の式を配置するテクニックが威力を発揮する。
sealed class PaymentMethod {}
class CreditCard extends PaymentMethod {}
class BankTransfer extends PaymentMethod {}
class CryptoCurrency extends PaymentMethod {} // 後から追加されたとする
String processPayment(PaymentMethod method) {
return switch (method) {
CreditCard() => ‘Processing credit card…’,
BankTransfer() => ‘Processing bank transfer…’,
// CryptoCurrency の処理が未実装の場合、
// もしここで _ => throw などを使わないと網羅性エラーになるか、
// あるいは網羅性を強制するためにあえて残す場合がある。
// 逆に、すべてのケースを網羅した上で、
// 「ここには絶対に到達しない」ことをコンパイラに教える場合：
_ => _unreachable(method),
};
}
// Never を返すヘルパー関数
Never _unreachable(Never value) {
throw UnsupportedError(‘Unsupported payment method: $value’);
}
なぜこれがコンパイル時に機能するのか？
ここで鮮やかなのは、`_unreachable` 関数の引数型が `Never` である点だ。
Dart の型推論とフロー解析において、`switch` の網羅性チェックを通過しなかった残りの型空間（この場合は `CryptoCurrency` など）が `_ =>` に流れ込む。
もしすべての既知のサブタイプが上のアームでキャッチされていれば、`_`（ワイルドカード）にマッチしうる残りの型は存在しない。つまり、`_` の中の推論される型は `Never` に縮小される。
引数が `Never` である関数 `_unreachable(Never value)` に、型が `Never` に収束した変数渡すことは、「このコードパスは到達不能（Dead Code）である」という事実をコンパイラが型レベルで受理したことを意味する。
もし将来、新しいサブタイプが追加され、上のアームでの処理が漏れた場合、`_` に流れ込む型はもはや `Never` ではなくなり（例：`CryptoCurrency` という具体的な型を持つ）、`Never` 型を要求する `_unreachable` に渡せなくなるため、見事にコンパイルエラーとして検出される。
—
4. 低レイヤ最適化と Dart VM の挙動
このイディオムは、単なる「型の安全性の担保」にとどまらず、JOT/AOTコンパイラ（Dart VM / AppJIT / AOT）の最適化にとっても極めて重要なヒントを与える。
1. デッドコード除去（Dead Code Elimination）
コンパイラは、`Never` 型を返すパスや、到達不能と判定された分岐ツリーを、中間表現（IR: Intermediate Representation）の段階で最適化の対象とする。これにより、不要なジャンプ命令やパターンのフォールスルー処理が機械語レベルで削ぎ落とされる。
2. インラインキャッシュ（IC）の汚染防止
ポリモーフィックなディスパッチが発生するコードパスにおいて、想定外の型が流れてこないことが型システムによって保証されるため、Dart VM のインラインキャッシュ（Inline Cache）やType Feedback Metadataがクリーンに保たれる。これにより、メガモーフィック・コール（Megamorphic Call）への墜落を防ぎ、コンパイル後のネイティブコードの実行速度を極限まで維持できる。
—
5. 実践：堅牢なステートマシーンの構築
以下のコードは、金融系トランザクションを模した、絶対に破綻してはならないステートマシーンの極限実装である。
sealed class Transaction {}
class Pending extends Transaction {
final double amount;
Pending(this.amount);
}
class Authorized extends Transaction {
final String authId;
Authorized(this.authId);
}
class Settled extends Transaction {
final DateTime settledAt;
Settled(this.settledAt);
}
/// 到達不能コードをコンパイル時に封じ込める完全網羅型トランスレータ
String evaluateTransaction(Transaction tx) {
return switch (tx) {
Pending(amount: var a) => ‘Transaction is pending with amount: \$$a’,
Authorized(authId: var id) => ‘Transaction authorized. AuthID: $id’,
Settled(settledAt: var time) => ‘Transaction settled at $time’,
// 万が一、将来新しい Transaction のサブタイプが追加され、
// 上記の記述が漏れた場合、この行の型推論が Never から外れ、
// コンパイルエラーとして開発者に即座に通知される。
_ => _panicOnUnreachableTransaction(tx),
};
}
Never _panicOnUnreachableTransaction(Never unexpected) {
// セキュリティ監査やメモリダンプのトリガーとしても機能する
// 実行時防壁
throw StateError(‘FATAL: Unreachable transaction state reached: $unexpected’);
}
void main() {
Transaction tx = Authorized(‘AUTH-99281-X’);
print(evaluateTransaction(tx));
}
—
結び：型システムを「武器」として使い倒す
多くのプログラマーは、型システムを「バグを防ぐための窮屈なガードレール」と捉えがちである。しかし、シニアエンジニアやアーキテクトにとって、型システムとは「論理の矛盾を物理的に排除するための鋭利な防壁」に他ならない。
Dart 3 のパターンマッチングと `Never` 型を組み合わせたこのイディオムは、ランタイムの不確実性をコンパイル時の絶対的確実性へと昇華させる。コードの行数を増やすことなく、システムの信頼性を極限まで高める――これこそが、Dart の底力を引き出すプロフェッショナルのアプローチである。