序文：制御構文から「計算」への昇華
Dart 3のリリースは、単なるマイナーアップデートではなかった。それは、Dartが「手続き型言語の制約」を脱ぎ捨て、関数型言語の持つ「式の純粋性」を型システムの深淵に統合した転換点である。
長年、Dart VMやAOTコンパイラの内部実装に携わってきた我々にとって、`switch`が「文（Statement）」から「式（Expression）」へと進化したことは、単なるボイラープレートの削減を意味しない。それは、静的解析によるプログラムの完全性証明と、コントロールフローグラフ（CFG）の最適化における決定的なパラダイムシフトである。
本稿では、Dart 3のswitch式が、どのようにしてコンパイル時の安全性を担保し、実行時の計算コストを最小化するのか。その深層を解剖する。
—
1. 宣言的代入とSSA（Static Single Assignment）への最適化
従来の`switch`文における最大の欠陥は、変数の初期化漏れのリスクと、`final`制約を付与できないことによる可変性の混入であった。
// 負の遺産：手続き的スイッチ
String statusMessage; // 命令的に宣言
switch (state) {
case State.idle:
statusMessage = ‘Waiting’;
break;
case State.busy:
statusMessage = ‘Processing’;
break;
// defaultを忘れるとstatusMessageはnullのまま、あるいは実行時エラーへ
}
Dart 3のswitch式は、このプロセスをアトミックな「評価」へと変貌させる。
// 洗練：式としてのスイッチ
final statusMessage = switch (state) {
State.idle => ‘Waiting’,
State.busy => ‘Processing’,
};
コンパイラ視点での利点
このコードにおいて、Dartコンパイラ（FEFE: Front-End Front-End）は、`statusMessage`が全てのパスで確実に初期化されることを静的に保証する。これはLLVM IR等に変換される前段階で、SSA（静的単一代入）形式へのマッピングを極めてクリーンにする。
不要なミュータビリティを排除することで、AOTコンパイラはレジスタ割り当てを最適化し、メモリバリアを最小限に抑えることが可能になる。実行時、これはCPUのブランチ予測を助け、パイプラインストールを低減させる。
—
2. 網羅性チェック（Exhaustiveness Checking）の数学的証明
セキュリティ研究者やシニアエンジニアが最も注目すべきは、`sealed`クラスと組み合わせた際の網羅性チェック（Exhaustiveness Checking）である。
sealed class AuthEvent {}
class LoginRequested extends AuthEvent { final String user; LoginRequested(this.user); }
class LogoutRequested extends AuthEvent {}
class PasswordResetRequested extends AuthEvent { final String email; PasswordResetRequested(this.email); }
String handleEvent(AuthEvent event) {
return switch (event) {
LoginRequested(user: var u) => ‘Logging in $u’,
LogoutRequested() => ‘Logging out’,
// PasswordResetRequested が欠けている場合、コンパイルエラーが発生する
};
}
防御的プログラミングの終焉
従来の`switch`では、未知のサブタイプに対する`default: throw UnimplementedError()`が必須であった。これは実行時にしか牙を剥かない。しかし、`sealed`な型階層におけるswitch式は、型システムが「宇宙のすべて（全ケース）」を把握していることを前提とする。
コンパイラは、階層構造を「直和型（Sum Type）」として扱い、全リーフノードがパターンにマッチするかをグラフ理論的に検証する。これにより、リファクタリング時に新しい型を追加した瞬間、プロジェクト内の全ての不完全なswitch式がエラーとして浮き彫りになる。これは「防御」ではなく「設計による回避」である。
—
3. パターンマッチングとメモリ効率
Dart 3のswitch式は、単なる値の比較に留まらない。オブジェクトの非構造化（Destructuring）をインラインで行う。
final result = switch (response) {
(int code, String body) when code >= 200 && code < 300 => ‘Success: $body’,
(int code, _) => ‘Error: $code’,
};
低レイヤでの挙動：スタックとヒープ
ここでのタプル` (int code, String body) `の展開は、Dart VMにおいて極めて効率的に処理される。Dart VMの最適化コンパイラは、このパターンマッチを、オブジェクトのフィールドへのダイレクトアクセス（オフセット計算）へとインライン化する。
特に、`when`句（ガード条件）を伴う場合、コンパイラはこれを一連の条件付きジャンプ命令へと変換する。従来の`if-else`の連鎖と比較して、switch式はジャンプテーブル（Jump Table）を生成しやすい構造を持っており、計算量は $O(1)$ または $O(\log n)$ まで圧縮される。
—
4. イベントループと非同期境界における安全性
DartのIsolateモデルにおいて、メッセージパッシングは生命線である。Isolate間を跨ぐデータ、あるいは`Stream`から流れてくる不透明なデータを処理する際、switch式は「データの正規化境界」として機能する。
Future
// 外部からの信頼できない入力を、型安全な領域へ強制的に引き込む
final command = switch (rawData) {
{‘type’: ‘start’, ‘id’: int id} => StartCommand(id),
{‘type’: ‘stop’} => StopCommand(),
_ => throw SecurityException(‘Invalid protocol format’),
};
// 以降、commandは完全に型保証された状態で処理される
_execute(command);
}
セキュリティの観点から見れば、これは「入力バリデーション」と「型変換」を不可分なアトミック操作にしている。不完全なデータ構造がシステムの深部へ浸透（Propagate）する前に、switch式の網羅性とガード条件が「防壁」として機能するのだ。
—
結言：アーキテクトとしての選択
Dart 3のswitch式を採用することは、単にコードを短くすることではない。それは、不確定要素をコンパイル時に排除し、ランタイムの挙動を決定論的なものへと昇華させる行為である。
ボイラープレートが消えた後のコードに残るのは、ビジネスロジックの純粋な意図と、型システムによる強固な証明だ。我々チーフアーキテクトが目指すべきは、常に「実行されるまで結果がわからないコード」を減らし、「コンパイルが通った時点で勝利が確定しているコード」を増やすことにある。
Dart 3のswitch式を掌握せよ。それは、堅牢なシステムを構築するための最強の「盾」であり、複雑性を切り裂く「矛」となる。