Dartの極限最適化：`Never`型とパターンマッチングが織りなす「到達不能」の静的証明
Dart 3におけるパターンマッチングと網羅性検査（Exhaustiveness Checking）の導入は、言語の表現力を一段上のレイヤへと引き上げた。しかし、真のシニア・エンジニアやランタイムの挙動にこだわるアーキテクトが注目すべきは、単なる構文の糖衣ではない。
コンパイル時解析（CFA: Control Flow Analysis）の限界を突破し、型システムとランタイムの境界線を極限まで最適化する鍵――それこそが `Never`型 である。
本稿では、Dart VMの型推論とAOT（Ahead-Of-Time）コンパイラが「到達不能（Unreachable）」なコードパスをどのように検知・排除し、無駄なジャンプ命令や分岐コストを削ぎ落としているのか、その深層メカニズムを紐解く。
—
1. ボトム型としての `Never` と静的解析の根幹
Dartの型階層の底辺には、すべての型のサブタイプである `Null` と並び、すべての型のサブタイプとして振る舞う `Never` が存在する。
Object?
│
(Nullable)
│
Object
│
┌──────┴──────┐
│ │
(others) Null
│ │
└──────┬──────┘
│
Never
`Never` 型の変数は、決して値を持つことができない。なぜなら、`Never` 型の値のインスタンス化は論理的に不可能だからだ。この特性を利用すると、関数が正常にリターンしないこと（例外の送出や無限ループなど）をコンパイラに厳密に伝えることができる。
コンパイル時のフロー解析と型昇格（Type Promotion）
DartのCFAは、コードパスの収束を監視している。関数が `Never` を返す場合、その呼び出し以降のコードは「絶対に実行されない」と静的に証明される。
T errorProofExecute
if (value == null) {
throw StateError(‘Value cannot be null’); // 戻り値の型は Never
}
// ここに到達した時点で、コンパイラは value が T 型であることを完全に保証する（Null安全の強制）
return value;
}
この強力な性質を、Dart 3のパターンマッチングにおける「網羅性検査のバイパスとデフォルトケースの安全な排除」に応用する。
—
2. Dart 3 パターンマッチングと網羅性チェックのジレンマ
Dart 3の `switch` 式や `switch` 文では、代数データ型（ADT）やシールドクラス（Sealed Classes）に対して網羅性チェックが行われる。すべてのバリエーションが網羅されていない場合、コンパイルエラーとなる。
しかし、将来的な拡張性や、予期せぬランタイムの状態を表現するために、デフォルトケース（`_`）を記述したくなる誘惑に駆られる。ここで問題が生じる。「本当に発生し得ないはずのフォールスルー」をどう扱うかだ。
一般的なコード：
sealed class NetworkState {}
class Loading extends NetworkState {}
class Success extends NetworkState {}
class Error extends NetworkState {}
String handleState(NetworkState state) {
return switch (state) {
Loading() => ‘Loading…’,
Success() => ‘Success!’,
Error() => ‘Error occurred.’,
_ => throw StateError(‘Unknown state’), // 冗長かつ、静的保証が弱い
};
}
上記のコードでは、`_ =>` が存在することで、コンパイラは「将来 `NetworkState` に新しいサブタイプが追加された時」に網羅性チェックの警告を発することができなくなる。さらに、ランタイムにおいては不要な例外ハンドリングのオーバーヘッドが残存する。
—
3. `Never` 型をデフォルトケースに配置する極限のパターンマッチング
ここで、デフォルトケースの型を明示的に `Never` にキャスト、あるいは `Never` を返す式を配置する。これにより、コンパイラに対して「このケースに到達した場合は、プログラムの不変条件（Invarint）が破壊されているため、直ちに実行を停止せよ」という強い型制約を突きつけることができる。
以下の実装を見てほしい。
sealed class DatabaseEvent {}
class Connect extends DatabaseEvent {}
class Query extends DatabaseEvent {}
class Disconnect extends DatabaseEvent {}
/// 網羅性を完全に担保しつつ、不正な型流入をコンパイル時になかったことにする関数
R _onUnreachableState
String processEvent(DatabaseEvent event) {
return switch (event) {
Connect() => ‘Establishing socket…’,
Query() => ‘Executing statement…’,
Disconnect() => ‘Closing connection…’,
// ここで `_` の代わりに Never 型の関数や throw 式を直接配置する
// Dartの型システムは Never が任意の型のサブタイプであることを利用し、
// 戻り値の型 String との整合性を自動的に解決する
};
}
なぜこれが強力なのか？
1. フォールスルーの静的遮断:
`DatabaseEvent` に新しいサブタイプ（例: `Reconect()`）が追加された瞬間、DartのCFAは「網羅されていない」としてコンパイルエラーを投げる。`_` を使った雑なフォールスルーを排除しつつ、安全性を担保できる。
2. バイトコードとAOTコンパイルの最適化:
Dart AOTコンパイラ（GenSnapshot）は、`Never` に帰着する分岐を解析する際、そのブロックが実行不可能であることを検知する。結果として、到達不能コードに対する無駄なジャンプテーブルのエントリや、レジスタ退避のコード生成をスキップする。
—
4. 低レイヤ視点：Isolateとイベントループにおける例外伝播のコスト削減
Dart VMはシングルスレッドのIsolateモデルで動作し、各Isolateは独自のヒープとイベントループを持っている。非同期処理やイベント処理のディスパッチにおいて、無駄な例外オブジェクトの生成はガベージコレクション（GC）の圧力となり、マイクロ秒単位のレイテンシを悪化させる。
伝統的なエラーハンドリングでは、到達不能なパスで `new Exception()` などをヒープ上にアロケートし、スタックトレースをキャプチャするコストが発生する。
しかし、`Never` を返して即座にVMのランタイムエラー（Panicに近い挙動）に持ち込む、あるいはコンパイル時になかったことにする構造をとることで、無駄なオブジェクト生成を回避できるケースがある。
// 高頻度でイベントループを回転させるディスパッチャーの核心部分
void dispatchEvent(DatabaseEvent event) {
// パターンマッチングによる分岐
final action = switch (event) {
Connect() => _handleConnect,
Query() => _handleQuery,
Disconnect() => _handleDisconnect,
// 到達不能パスを Never 型の式でハンドリング
// ランタイムに到達した場合、Isolateは即座に致命的エラーとして停止すべき性質を強制する
_ => _throwInvalidEvent(event),
};
action();
}
Never _throwInvalidEvent(DatabaseEvent event) {
// スタックトレース生成コストを抑制しつつ、VMの安全性を維持
throw StateError(‘Fatal: Unrecognized event type ${event.runtimeType}’);
}
void _handleConnect() {}
void _handleQuery() {}
void _handleDisconnect() {}
AOTコンパイラは、`_throwInvalidEvent` の戻り値が `Never` であることを知っているため、この関数呼び出し以降のレジスタ状態の復元コードを一切生成しない。関数呼び出しそのものが「プログラムの終端（Abort）」として扱われる。
—
5. 実践：セキュアかつ堅牢なステートマシンの構築
金融系や暗号学的プロトコルを扱う高信頼性システムにおいて、状態遷移の抜け漏れは致命的な脆弱性に直結する。最後に、`Never` 型を活用した堅牢なステートマシンの実装パターンを示す。
sealed class AuthState {}
class Unauthenticated extends AuthState {}
class Authenticating extends AuthState {}
class Authenticated extends AuthState {}
// 将来追加される可能性のある不正な拡張を弾く
// class Compromised extends AuthState {}
void evaluateSecurityContext(AuthState state) {
// すべての既知の状態を網羅。
// 万が一、型システムの隙間を縫って不正なインスタンスが渡された場合、
// 下記の default 句における Never 型へのキャストがコンパイル、
// あるいはランタイムの型安全性を極限まで高める防壁となる。
final String telemetryCode = switch (state) {
Unauthenticated() => ‘AUTH_001’,
Authenticating() => ‘AUTH_002’,
Authenticated() => ‘AUTH_003’,
};
_emitTelemetry(telemetryCode);
}
void _emitTelemetry(String code) {
// Low-level telemetry emission
}
もしここで `AuthState` に新しいサブタイプが追加され、かつ `switch` 式でハンドリングし忘れた場合、Dartコンパイラは容赦なくビルドを失敗させる。開発者は実行時エラー（Runtime Crash）に怯える必要がなくなり、コンパイラという最強の守護神にセキュリティの担保を委ねることができる。
—
アーキテクトからの提言
Dartの `Never` 型とパターンマッチングの融合は、単なる「コードを綺麗に見せるためのテクニック」ではない。
それは、「型システムによってプログラムの論理的破綻をコンパイル時に完全に封じ込め、ランタイムの無駄なオーバーヘッドを極限まで削ぎ落とす」という、システムアーキテクチャの根幹に関わる最適化手法である。
甘いフォールスルー（`_ =>`）をコードベースから駆逐せよ。すべての分岐には意図があり、到達不能な領域には `Never` の鉄槌を置くこと。それこそが、真に堅牢で高速なDartアプリケーションを構築唯一の道である。