Dart 3 switch式と論理和（`|`）パターン：ランタイム最適化の極限と静的解析の裏側
Dart 3におけるパターンマッチングの導入は、単なるシンタックスシュガーの追加ではない。C#やRustの系譜を汲みつつも、Dart VMのオブジェクトモデルとAOTコンパイラ（およびJITのCFA: Control Flow Analysis）の特性に深く最適化された強力な武器である。
特に、`switch`式における論理和（`|`）パターンを用いた分岐の統合は、ソースコードの可読性を飛躍的に高めるだけでなく、生成されるバイトコードおよび機械語の効率、そしてコンパイル時の型推論の精度にまで影響を与える。
本稿では、この `|` パターンがコンパイラによってどのように解釈され、実行時メモリやIsolateのイベントループにどう作用するのか、その低レイヤの真実を紐解く。
—
1. 従来の `switch` 文が抱えていたランタイムの無駄
Dart 2時代、複数の条件に対して同一の処理を適用する場合、フォールスルーを利用するか、論理OR（`||`）で条件を繋ぐしかなかった。
// [Dart 2 以前の悪夢] 冗長なフォールスルーと制御フローの肥大化
void handleLegacyState(AppState state) {
switch (state) {
case AppState.loading:
case AppState.fetching:
case AppState.authenticating:
_showSpinner();
break;
case AppState.success:
case AppState.loaded:
_renderContent();
break;
default:
_handleError();
}
}
このコードは、Dart VMのコンパイラ（Kernel/CFE: Common Front End）の視点において、各 `case` ラベルに対するジャンプテーブル（Jump Table）の構築を複雑にする。フォールスルーの多用は、CFG（Control Flow Graph）のパスを不必要に複雑化させ、JITのプロファイリング（ICs/Inline Cachesのヒット率）や、AOTコンパイラによる到達可能性解析（Dead Code Elimination）の最適化ウィンドウを狭める原因となっていた。
—
2. `switch` 式と論理和（`|`）パターンの本質
Dart 3の `switch` 式（StatementではなくExpression）とパターンマッチングは、これらの問題を根本から解決する。
// [Dart 3] パターンマッチングによる論理和の統合
void handleModernState(AppState state) {
final action = switch (state) {
AppState.loading | AppState.fetching | AppState.authenticating => () => _showSpinner(),
AppState.success | AppState.loaded => () => _renderContent(),
_ => () => _handleError(),
};
action();
}
コンパイラ視点での動作：ディスパッチの効率化
CFE（Common Front End）は、`|` で結合された論理和パターン（Logical-or pattern）を、単なる「人間向けの糖衣構文」ではなく、決定木（Decision Tree）アルゴリズムに基づく効率的なジャンプ構造へとコンパイルする。
複数のアトム（この場合は列挙型の定数）が `|` で結ばれている場合、VMはこれらを単一の等価性チェックの集合、あるいはハッシュ化されたジャンプターゲットとして評価する。これにより、無駄な分岐命令（branch instructions）が削減され、パイプラインハザードの確率が劇的に低下する。
—
3. 型の安全性とガード節（`when`）の組み合わせにおける知見
`|` パターンを使用する際の最大の罠であり、かつ強力な機能が「バインドされる変数のスコープ」である。論理和パターンの各分岐において、束縛される変数（Variable Pattern）の型と数が完全に一致していなければならないという厳格な静的制約がある。
これを誤ると、コンパイル時にCFAがエラーを吐く。
sealed class NetworkResult {}
class Success extends NetworkResult {
final String data;
Success(this.data);
}
class Cached extends NetworkResult {
final String cachedData;
Cached(this.cachedData);
}
class Loading extends NetworkResult {}
// 【危険なアンチパターン】
// 論理和の各アームで異なる変数名や型構造を混在させることはできない
void process(NetworkResult result) {
// 以下のコードはコンパイルエラーになる：
// パターン ‘Success(data: var d)’ と ‘Cached(cachedData: var c)’ は
// 同じ名前・型の変数をバインドしていないため。
}
正しい論理和とガード節の応用
複数の異なる型や構造を安全にまとめつつ、詳細な条件を付与する場合、パターンマッチングの網羅性と `when` ガード節を組み合わせる。
String evaluateResponse(NetworkResult result) => switch (result) {
// オブジェクトの構造が一致する場合の論理和
Success(data: var d) | Cached(cachedData: var d) when d.isNotEmpty => ‘Valid: $d’,
Success() | Cached() => ‘Empty Data’,
Loading() => ‘Loading…’,
};
このコードにおいて、`d` という変数は `Success` または `Cached` のどちらにマッチした場合でも、共通の親型（あるいは共通でアクセス可能なプロパティの型）として安全にスタック上に割り当てられる。
Dart VMは、このパターンマッチングの評価において、ヒープ上のオブジェクトヘッダ（Class ID）を一度だけ参照し、そのクラスIDが指定された複数のパターンのいずれかに合致するかを極めて高速に判定する（Class ID Based Dispatch）。
—
4. メモリとイベントループへの影響：なぜ可読性だけではないのか
シニアエンジニアとして注目すべきは、これがメモリレイアウトとIsolateのコンテキストに与える影響である。
1. アロケーションの回避:
`switch` 式は文（Statement）ではなく式であるため、不要なミュータブルなローカル変数の宣言を排除できる。イミュータブルなデータフローは、Dart VMのジェネレーショナルGC（世代別ガベージコレクション）において、エデン領域（Young Generation）での無駄なオブジェクト生成を防ぎ、マイナーGCの実行頻度を最小化する。
2. 非同期イベントループ（Microtask / Event Queue）との調和:
UIフレームワークや高スループットなバックエンドサービスにおいて、イベントループの各イテレーション（Tick）での処理遅延（Jank）は致命的である。複雑な `if-else` チェーンや冗長な `switch` 文は、分岐予測ミス（Branch Prediction Miss）を引き起こし、CPUパイプラインをストールさせる。
`|` パターンによって最適化されたコンパクトなジャンプテーブルは、CPUのキャッシュライン（L1/L2キャッシュ）に常駐しやすくなり、結果としてイベントキューからのタスク取り出しから処理完了までのレイテンシを極限まで削ぎ落とす。
—
5. 結論：アーキテクトが取るべき指針
Dart 3の `switch` 式と論理和（`|`）パターンは、単なるコードの行数削減ツールではない。
それは、開発者がコンパイラ（CFE & AOT/JIT VM）に対して「この分岐群は等価な意味論を持つ」という意図を明確に伝え、マシン語レベルでの最適化を引き出すための契約である。
冗長な `case` の羅列を排除し、論理和パターンでコードベースの熵（エントロピー）を低く保て。それこそが、大規模かつハイパフォーマンスなDart/Flutterアーキテクチャを統括するエンジニアリングの極意である。