Dartの「Never」型と「Null」型の深淵：型システムの境界を理解する
Dartの型システムは、Soundness（健全性）を根幹に据えて進化してきた。特にDart 2.12で導入された健全なNull安全（Sound Null Safety）と、Dart 3で完成を見たパターンマッチングおよび網羅性チェック（Exhaustiveness Checking）により、静的解析の精度は極限に達している。
しかし、シニアエンジニアやランタイムの挙動に踏み込む開発者であっても、型階層の底辺に君臨する `Null` 型と `Never` 型の境界、そしてそれらがAOTコンパイラやDart VMの実行時表現にどう影響するかを正確に理解している者は少ない。
本稿では、これら両者の型が型理論およびコンパイラ内部でいかに扱われ、どのように防壁としての堅牢なコード設計に応用できるかを、低レイヤの視点から解き明かす。
—
1. 型階層の底辺：`Null` と `Never` の位相幾何学
Dartの型システムは、すべての型の根底に `Object?` が存在し、その最下層に `Never` が位置する有向非巡回グラフ（DAG）を形成している。
Object?
│
(Nullable)
│
Null <--- (底辺の一つ：値を持てる唯一のボトム型ではないが...)
│
Never <--- (真のボトム型：値が存在しない)
`Null` 型の正体
`Null` 型は、`null` という単一の値のみを許容する型である。これはボトム型（Bottom Type）ではない。なぜなら、`null` という実態のある（あるいはポインタとしてのゼロ表現を持つ）ランタイムインスタンスが存在しうるからだ。
`Never` 型の正体
対して、`Never` は真のボトム型（Bottom Type）である。
型理論において、ボトム型は「値域（Domain of values）が空集合である型」を指す。つまり、`Never` 型の変数は、絶対に値を保持することができない。
コンパイラ（cfe: Common Front End）の視点において、関数が `Never` を返すということは、「その関数は決して正常に処理を完了せず、呼び出し元へ制御を返さない（例外を投げる、無限ループに入る、あるいはプロセスを終了する）」ことを保証する契約を意味する。
—
2. コンパイラとAOTにおける `Never` の最適化挙動
Dart VMやAOTコンパイラ（`gen_snapshot`）は、コード生成時に `Never` 型をどのように利用しているのか。
到達不能コード（Unreachable Code）の排除
コンパイラは、型が `Never` である式以降のコードを、CFG（制御フローグラフ）から完全に排除する。
Never terminate(String message) {
throw StateError(message);
}
void processCode(int? code) {
final validCode = code ?? terminate(‘Code cannot be null’);
// ここに到達した時点で、コンパイラは `code` が決して null でないことを静的に証明している。
// ランタイムにおいて null チェックの機械語命令（Branch if null）は一切生成されない。
print(validCode.isEven);
}
AOTコンパイラは、`terminate` が `Never` を返すことを知っているため、`??` 演算子の右辺が評価された場合、制御フローは必ずそこで途切れる。したがって、後続の `validCode` のアンラップ処理におけるオーバーヘッドはゼロになる。これは、Dartのパフォーマンス最適化における隠れたキーストロークである。
—
3. Dart 3 パターンマッチングと `Never` による網羅性チェックの強制
Dart 3のスイッチ式とパターンマッチングにおいて、`Never` は「これ以上パターンが存在しないこと」をコンパイラに証明するための強力な武器となる。
以下の、ドメイン駆動設計（DDD）におけるステートマシンの網羅性チェックを見てほしい。
sealed class NetworkState {}
class Idle extends NetworkState {}
class Loading extends NetworkState {}
class Success extends NetworkState {}
// 拡張性のため、将来的に Error が追加されるかもしれない
class ErrorState extends NetworkState {
final String message;
ErrorState(this.message);
}
String handleState(NetworkState state) {
return switch (state) {
Idle() => ‘待機中’,
Loading() => ‘読み込み中’,
Success() => ‘成功’,
ErrorState(message: var msg) => ‘エラー: $msg’,
};
}
もし将来、`NetworkState` に新しいサブタイプ `Timeout` が追加された場合、上記のコードはコンパイルエラー（Exhaustiveness error）を吐き出す。これはシニアエンジニアにとって望ましい挙動だ。
しかし、「予期せぬ型が流れ込んできた場合」や、意図的にデフォルトケースを排除しつつ、型システムの穴を突く防壁を作りたいときはどうするか。ここで `Never` が活きる。
// 型の底辺を利用した、絶対に実行されないことを保証するトラップ関数
Never _unhandledState(NetworkState state) {
// 実行時にもしここに来たら、それはコンパイル時の想定を超えた不正なメモリ状態か、
// 不完全なキャストが行われたことを意味する。
throw UnsupportedError(‘Unhandled state: ${state.runtimeType}’);
}
String handleStateStrict(NetworkState state) {
return switch (state) {
Idle() => ‘待機中’,
Loading() => ‘読み込み中’,
Success() => ‘成功’,
ErrorState(message: var msg) => ‘エラー: $msg’,
// ここで網羅性が保証される。
// 仮に網羅されていない場合、switchの型は残りのサブタイプと合致しなければならないが、
// _unhandledState の戻り値が Never であるため、どんな型が要求される文脈にも適合する。
_ => _unhandledState(state),
};
}
なぜこれが機能するのか？
`Never` はすべての型のサブタイプであるため、`switch` 式の戻り値型（この場合は `String`）に対し、`_unhandledState(state)`（型は `Never`）は型安全に合致する。コンパイラは「この分岐は決して正常値（String）を返さず例外を投げる」と解釈するため、型矛盾を起こさない。
—
4. イベントループとIsolate境界における型安全の防壁
Dartの非同期処理モデル（Event Loop）において、`Never` と `Null` の境界を意識することは、メモリリークや不正なメッセージパッシングを防ぐ上で極めて重要である。
特に、Isolate間でデータをやり取りする際、`Never` 型そのものをシリアライズして送ることはできない（値が存在しないのだから当然だ）。しかし、「処理の終端（Dead End）」を示すシグナルとして `Never` を用いた設計は、非同期パイプラインの堅牢性を劇的に高める。
以下の、ストリーム処理における例外伝播と型強制のパターンを提示する。
import ‘dart:async’;
/// ストリームのパイプラインを強制終了させるためのガーディアン関数
Never abortPipeline(String reason) {
throw ConcurrentModificationError(‘Pipeline aborted: $reason’);
}
void processEventStream(Stream
stream.listen(
(data) {
if (data < 0) {
abortPipeline('Negative data received in secure channel.');
}
// 通常処理
print('Processed: $data');
},
onError: (Object error, StackTrace stackTrace) {
// エラーハンドリング
print('Caught: $error');
},
);
}
このコードにおいて、`abortPipeline` が呼ばれた瞬間、イベントループのそのイテレーションにおける後続処理は即座に破棄され、IsolateのクラッシュあるいはZoneのエラーハンドラへ制御が移譲される。
ここで `Null` (`null`) を返してしまうと、呼び出し元で「値として処理を継続すべきか？」という曖昧さが生まれてしまう。`Never` を使うことで、「ここから先には絶対にコードが存在しない」という絶対的な不変条件（Invariant）をコードの構造に刻み込むことができるのだ。
—
5. チーフアーキテクトからの提言：防衛的プログラミングの極致
多くのプログラマは、型を「データを格納する箱のラベル」程度にしか考えていない。しかし、DartのC++およびRustの系譜を引く高度な型システムにおいて、型は「プログラムが絶対に踏み込んではならない領域を定義する物理法則」である。
- `Null` は「存在しないかもしれない値」の表現であり、ランタイムに実体を持つ。
- `Never` は「コードの存在そのものの否定」であり、コンパイル時における論理的防壁である。
この境界を正確に把握し、網羅性チェックやボトム型の性質をコードの隅々にまで適用することで、実行時エラーの芽をコンパイル段階で完全に摘み取ることが可能となる。
Dartの真の力を引き出したいのであれば、`dynamic` や安易な `null` 許容に逃げるのではなく、`Never` が持つ圧倒的な静的解析能力をあなたのアーキテクチャの礎石としなければならない。