Dart 3 パターンマッチングの深淵：ガード句（`when`）の評価順序とコンパイラ最適化の全貌
Dart 3で導入されたパターンマッチングとレコード（Records）は、言語の表現力を劇的に拡張した。しかし、構文の背後にあるDart VMやAOT（Ahead-Of-Time）コンパイラの挙動、特にガード句（`when` clause）の評価順序と実行時コストまで意識してコードを書いているエンジニアはどれほどいるだろうか。
本稿では、一般的なリファレンスには載っていない、Dartランタイムの心臓部に踏み込んだ「ガード句の低レイヤ挙動」を解剖する。
—
1. パターンマッチングとガード句のコンパイルモデル
Dart 3の `switch` 式や `case` 文におけるパターンマッチングは、単なる連続した `if-else` の糖衣構文ではない。CFA（Control Flow Analysis）と連動した型推論、そして網羅性チェック（Exhaustiveness checking）を伴う高度なジャンプテーブル・決定木（Decision Tree）の構築としてコンパイルされる。
ここで問題になるのが `when` ガード句 である。
パターンマッチングにおけるマッチングプロセスは、以下の2つのフェーズに厳密に分離される。
1. 構造的マッチング（Structural Matching）: オブジェクトの型、形状（Shape）、プロパティがパターンに合致するかを静的・動的に検証する（O(1)〜O(N) の最適化木）。
2. 意味的評価（Semantic Evaluation / Guard）: ガード句（`when
コンパイラ（CFE: Common Front-End）およびバックエンド（Dart VMのJIT/AOTコンパイラ）は、構造的マッチングのコストを最小化するよう最適化するが、ガード句の中身は「任意のコード」であるため、コンパイル時最適化のセーフティネットの外に置かれる。
—
2. ガード句の評価順序の決定論
Dart言語仕様において、複数の `case` が存在する場合の評価順序は、ソースコード上に記述された上から下への順序（Top-to-bottom order）が保証される。しかし、同一 `case` 内のパターン要素とガード句の評価順序、および複数アーム間でのショートサーキットの挙動には注意が必要だ。
以下のコードを見てほしい。
sealed class NetworkEvent {}
class DataEvent extends NetworkEvent {
final Map
DataEvent(this.payload);
}
class ErrorEvent extends NetworkEvent {
final int errorCode;
ErrorEvent(this.errorCode);
}
void processEvent(NetworkEvent event) {
switch (event) {
// パターン1: 構造マッチ + 重いガード句
case DataEvent(:var payload) when _isAuthorized(payload) && _hasValidSchema(payload):
_handleData(payload);
break;
// パターン2
case DataEvent(:var payload) when _isCacheHit(payload):
_handleCache(payload);
break;
case ErrorEvent(:var errorCode):
_handleError(errorCode);
break;
}
}
bool _isAuthorized(Map
bool _hasValidSchema(Map
bool _isCacheHit(Map
void _handleData(Map p) {}
void _handleCache(Map p) {}
void _handleError(int e) {}
VMの視点から見た実行フロー
1. Dart VMはまず、`event` のランタイム型が `DataEvent` であるかをチェックする（クラスIDの比較のみのため極めて高速）。
2. 型が一致した場合、構造的分解（Destructuring）により `payload` の参照がレジスタまたはスタックにロードされる。
3. ここからがガード句の領域である。
`when` 節の式 `_isAuthorized(payload) && _hasValidSchema(payload)` が通常の関数呼び出しとして評価される。
ここで重要なのは、ガード句内の式は短絡評価（Short-circuit evaluation）を行うが、ガード句自体は上から順に評価されるという点だ。
もし `_isAuthorized` が重いI/Oバウンド、あるいはCPUバウンドな処理である場合、不適切な順序で配置すると、無駄なサイクルを大量に消費することになる。
—
3. パフォーマンスとメモリを蝕む「暗黙のボクシング」
シニアエンジニアが最も警戒すべきは、ガード句内での不要なオブジェクトアロケーション（ボクシング）と、それによるGC（ガベージコレクション）プレッシャーだ。
Dartは優れた世代別GC（Generational GC）を持つが、ホットパス（Hot path）で頻繁にレコードやオブジェクトを生成・破棄すると、マイナーGCの頻度が増加し、フレームドロップ（Jank）を引き起こす。
特に、パターンマッチング内でレコードやコレクションの操作を行う場合、コンパイラが一時的なインスタンス化を避ける最適化（Escape Analysis）を行えないケースがある。
// アンチパターン：ガード句内で毎回レコードやコレクションを生成している例
switch (metrics) {
case (var cpu, var memory) when (cpu + memory) > 90 && _isSystemCritical():
// …
break;
}
コンパイラ最適化を引き出す書き方
Dart VMのAOTコンパイラ（特にネイティブコード生成時）に優しく、Isolateのイベントループをブロックしないための鉄則を以下に挙げる。
1. コストの低いガードを左に、高いガードを右に置く（短絡評価の徹底）
`&&` 演算子の左側には、プリミティブな比較やローカル変数のチェックを置き、重い関数呼び出しは右側に置く。
case DataEvent(:var payload) when payload[‘status’] == 200 && _expensiveValidation(payload):
2. ガード句内での関数呼び出しのインライン化
DartのCFEは小さなメソッドをインライン化するが、ガード句内の複雑なロジックはインライン化の恩恵を受けにくい場合がある。事前にローカル変数に落とし込むか、純粋関数（Pure function）として記述し、VMの型フィードバック（Type Feedback）を有効にする。
3. 網羅性（Exhaustiveness）を汚染しない
`when` 句を使用すると、コンパイラはそれを「完全な網羅」とみなさない場合がある（ガードが偽だった場合のフォールバックが必要になる）。網羅性チェックの恩恵を最大限に受けるため、ガード句は「型の一致後の細かい条件分岐」に限定し、ベースの型分岐はプレーンなパターンで行うこと。
—
4. イベントループとIsolateの文脈における考察
Dartはシングルスレッド（正確にはIsolate単位のイベントループモデル）で動作する。非同期イベントや巨大なメッセージパッシングの処理中に、複雑なパターンマッチングと高負荷なガード句が走ると、マイクロタスクキューやイベントキューの処理が遅延する。
特に、FFI（Foreign Function Interface）やIsolate間のポート通信で受け取ったデータを即座にデシリアライズ・パターンマッチングする際、ガード句で重い計算を行うと、UIスレッドやワーカースレッドのレイテンシが致命的に悪化する。
[Isolate Message Received]
↓
[Structural Matching (Fast O(1))]
↓
[Guard Evaluation (Slow/Arbitrary Code)] ──(重い処理)──> [EventLoop Block]
↓
[Action Execution]
このボトルネックを防ぐためには、ガード句は「真偽値を即座に返す述語（Predicate）」に徹し、重いビジネスロジックやデータ変換はマッチングの成功後に遅延実行（Lazy execution）させるというアーキテクチャ上の境界線を引くことが極めて重要である。
—
5. 結言
Dart 3のパターンマッチングは、単なる「スタイリッシュな構文糖」ではない。それは静的型システムとランタイムパフォーマンスの極限の融合点である。
ガード句（`when`）を使いこなすとは、コンパイラの評価モデルとDart VMの実行コストを完全に掌握することと同義である。記述の美しさに溺れず、裏で何が起きているのかの解像度を常に高く保て。それこそが、真にスケーラブルなDart/Flutterアーキテクチャを構築する唯一の道である。