【テクニカル・上級編】Dartの「リストパターン」における可変長マッチングと、スプレッド演算子の微妙な関係 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dart 3 リストパターンの深層：可変長マッチングとスプレッド演算子のコンパイラ戦術

Dart 3の導入によって、私たちの言語表現力は劇的な進化を遂げた。特にパターンマッチングとデストラクチャリングの統合は、構文解析木の構造を宣言的に分解することを可能にし、ランタイムにおける分岐コストを極限まで最適化する道を開いた。

しかし、この強力な抽象化の裏側で、シニアエンジニアが把握していなければならない領域がある。それが「リストパターン（List patterns）」における可変長マッチングと、スプレッド演算子（`…`）の微妙な関係性だ。

本稿では、Dart VMのコンパイラがこの構文をどのように解釈し、メモリ上でどのような配列操作に変換しているのか、その低レイヤの真実を暴く。

—

1. リストパターンと可変長マッチングの基本構造

Dartのリストパターンでは、固定長の要素マッチングだけでなく、`…`（スプレッド演算子）を使用することで、可変長のサブリストをキャプチャできる。

// 可変長マッチングの基本例
void processTokens(List tokens) {
switch (tokens) {
// 先頭が ‘GET’ で、末尾が ‘HTTP/1.1’ の場合、中身を可変長でキャプチャ
case [‘GET’, …var path, ‘HTTP/1.1’]:
print(‘GET request for path segments: $path’);
break;
default:
print(‘Unknown signature’);
}
}

このコードは一見して直感的だが、コンパイラの視点では何が起きているのか？
内部的には、Dart VM（またはAOTコンパイラ）は、このパターンマッチを単純な線形探索ではなく、「長さの検証」と「特定インデックスの直接参照」の組み合わせにコンパイルする。

—

2. コンパイラ最適化の裏側：なぜスプレッドの位置が重要なのか

DartのCFA（Control Flow Analysis）およびパターンビルダーは、スプレッド演算子（`…`）の位置に対して極めて厳格な制約を課している。

制限：スプレッドは1つのリストパターンにつき「最大1つ」まで

以下のコードはコンパイルエラーになる。

// 【コンパイルエラーの例】
// 複数の可変長スプレッドは曖昧性（Ambiguity）を生むため禁止されている
case [var head, …var middle, …var tail]:

なぜこの制約が存在するのか？
数学的に言えば、可変長配列のセグメンテーションにおいて、2つ以上の可変長要素が混在すると、マッチングの計算量が $O(N)$ から最悪の場合バックトラッキングを伴う指数関数的複雑性に跳ね上がるからだ。Dartコアチームの設計思想として、ランタイムの予測可能性（Predictability）と決定論的な実行速度（Deterministic execution）が常に優先される。

したがって、スプレッドが許されるのは「単一のセグメント」のみであり、コンパイラはこれを一意の引き算（例：`totalLength – fixedElementsCount`）として定数時間 $O(1)$ に近いコストで処理できるようにコードを生成する。

—

3. メモリ割り当てとアロケーションの罠：キャプチャ変数のコスト

ここでシニアエンジニアとして最も警戒すべきは、可変長マッチングにおけるメモリのアロケーション（Allocation）である。

以下のパターンを見てほしい。

void analyzeBuffer(List buffer) {
if (buffer case [0xFF, …var payload, 0x00]) {
// payload は新しい List として割り当てられるか？
}
}

Dart VMのメモリ最適化戦略

Dart 3のランタイムにおいて、`…var payload` のようなキャプチャは、元のリストのビュー（View）ではなく、原則として新しいサブリスト（ダンプされたコピー、あるいは効率的なサブ配列のラップ）の生成を伴う。

もしこれが高頻度で呼び出されるネットワークパケットのデコード処理や、イベントループ（Event Loop）のマイクロタスクキューを大量に消費するホットスポットで行われた場合、不要なGC（ガベージコレクション）プレッシャーを生む原因となる。

【防壁を突破する極限の知見】

パフォーマンスが極限まで求められる文脈では、パターンマッチングによるリストのキャプチャを避け、明示的なインデックスアクセスと `List.view`（あるいは効率的なジェネリック範囲指定）を検討すべきだ。しかし、可読性のトレードオフを許容できるのであれば、パターンマッチングはコードの安全性を飛躍的に高める。

—

4. 厳密な型推論とガード節の連携

リストパターンとスプレッドを組み合わせる際、型安全性を担保するためのガード節（`when`）との連携は非常に強力だ。しかし、ここでもコンパイル時の型解決に起因する罠がある。

void evaluateCommand(List