Dart型昇格の深淵：なぜフィールドは昇格せず、ローカル変数は昇格するのか
DartのCFA（Control Flow Analysis：制御フロー解析）は、言語仕様の洗練された美しさと、ランタイムの極限的な最適化が交差するアリーナである。
多くの開発者は、`if (x is String)` というガード節の直後で `x` が自動的に `String` へキャストされる「型昇格（Type Promotion）」の恩恵を日常的に受けている。しかし、クラスのフィールド（プロパティ）に目を向けた途端、その魔法は突如として消失する。
「なぜ、ローカル変数は昇格するのに、インスタンスフィールドは昇格しないのか？」
この問いに「そういう仕様だから」と答えるのは、コンパイラの内部構造を放棄するに等しい。本稿では、Dartの静的解析器（Analyzer）からDart VMのメモリアクセスモデル、さらにはIsolateの並行性（Concurrency）に至るまで、型昇格の境界線を貫く根本的な物理法則を解き明かす。
—
1. 制御フロー解析（CFA）と変数の「不変性」の幻想
まず、DartのCFAがどのように変数を追跡しているかを定義する。
ローカル変数が型昇格の対象となる条件は厳格だ。「その変数が、解析対象のスコープ内において、エイリアスされず、かつ再代入されない（あるいはCFAが追跡可能な範囲で安全である）こと」。
以下のコードを見てほしい。
void examineLocal(Object? value) {
if (value is String) {
// ここで value は String に昇格する
print(value.toUpperCase());
}
}
このとき、CFAはスタックフレーム上に割り当てられたローカル変数 `value` のライフサイクルを完全に掌握している。この関数を実行するスレッド（またはIsolateの制御フロー）において、単一の実行コンテキスト内にあるローカル変数は、他のコンテキストから勝手に書き換えられる心配がない。
しかし、これをクラスのフィールドに置き換えると、解析器は途端に解析を放棄する。
class HoldTheLine {
Object? value;
void examineField() {
if (this.value is String) {
// エラーまたは昇格しない：
// 「The member ‘toUpperCase’ can’t be used for ‘Object?’, because of its type.’」
print(this.value.toUpperCase());
}
}
}
なぜか？ 答えは 「エイリアス（Aliasing）と非同期競合（Race Conditions / Interleaving）」 にある。
—
2. フィールドが昇格しない根本原因：エイリアスと非同期性の罠
インスタンスフィールドは、オブジェクトのヒープ領域（Heap）に存在する。ヒープ上のメモリは、ポインターを通じて複数の場所から参照（エイリアス）され得る。
ここにDart特有の、そしてモダン言語共通の致命的な問題がある。「同期的な制御フローの最中であっても、フィールドの値は外部から書き換えられうる」 という事実だ。
シナリオ：ゲッターの副作用と非同期インターリーブ
Dartはシングルスレッド（Event Loop駆動）で動作するが、`await` などの非同期境界を挟むと制御が移譲される。しかし、`await` がなくとも、フィールドが カスタムゲッター（Custom Getter） を持っていた場合どうなるか？
class UnstableContainer {
Object? _internalValue = ‘Hello’;
// 任意の副作用を持つゲッター
Object? get value {
// ここで内部状態を書き換えたり、別の非同期処理をトリガーする可能性がある
return _internalValue;
}
}
もしCFAがインスタンスフィールドの型昇格を許可した場合、以下の矛盾が生じる。
1. `if (obj.value is String)` の評価時にゲッターが走る。
2. その直後の処理（ブロック内）で、再度 `obj.value` にアクセスした際、別のゲッターや副作用によって値が `int` や `null` にすり替わっているかもしれない。
3. 解析器が「ここはStringだ」と保証した型安全性の神話が、ランタイムの物理的な実態によって崩壊する。
これを防ぐため、Dart言語仕様（Language Specification）では、「オブジェクトのフィールド（`this.f`, `obj.f`）やトップレベル変数、静的変数は、たとえ `final` であろうとも、型昇格の対象外とする」 と厳格に定められている。
—
3. コンパイラとメモリモデルの視点：なぜフィールドの追跡は不可能なのか
CFAのアルゴリズム的限界についても言及しておこう。
ローカル変数はSSA（Static Single Assignment：静的単一代入）形式に変換しやすい。スタック上のスロットに対するインデックスとして扱えるため、制御フローグラフ（CFG）上での型の伝播（Type Propagation）を極めて低コストで計算できる。
一方、フィールドアクセス（`x.y`）は以下の要素を伴う：
- レシーバー `x` 自体が何者であるか（`x` もまたフィールドや複雑な式の可能性がある）。
- オブジェクトのメモリレイアウト（Class Descriptor）を通したオフセット解決。
- カプセル化の壁（Encapsulation Barrier）。
仮に、あるクラスのフィールドが `final` で、かつゲッターを持たないプレーンなインスタンス変数であったとしても、Dartの静的解析器は「保守的なアプローチ（Conservative Approach）」をとる。すべてのインスタンスフィールドの昇格を例外なく禁止することで、コンパイラの複雑性を爆発させず、予測可能なセマンティクスを維持しているのだ。
—
4. 回避策：ローカル変数へのシャドーイング（Shadowing）
シニアエンジニアとして、この制限を突破するためのイディオムは常時武器として持っておくべきである。フィールドの値を安全に扱いたい場合、一度ローカル変数に退避させる。これがDartにおける唯一にして正当な型昇格のハックである。
class SecureProcessor {
Object? payload;
SecureProcessor(this.payload);
void process() {
// フィールドをローカル変数にローカルコピー（シャドーイング）する
final currentPayload = payload;
if (currentPayload is String) {
// ここで currentPayload は String に型昇格する！
// なぜなら、currentPayload はこのスコープ内の不変なローカル変数だからだ。
print(currentPayload.length);
print(currentPayload.toUpperCase());
}
}
}
このパターンの低レイヤにおける意味
`final currentPayload = payload;` を実行した瞬間、ヒープ上にああったフィールドの値（への参照）が、現在のスタックフレーム上のローカル変数スロットにコピーされる。
以降、このローカル変数は外部の何者からも書き換えられることが保証されるため、CFAは安全に型を昇格させ、後続のコードで仮想メソッド呼び出し（Vtable Dispatch）の最適化や、不要なキャストチェックの排除を行うことができる。
—
5. まとめ：型昇格の境界線を知る者
Dartの型昇格が機能しない境界線、それは 「その変数が、プログラムの他の部分から観測・改変される可能性のある共有メモリ（Heap）に属しているか否か」 という一点に集約される。
- ローカル変数: スタック上。孤立しており、安全。 → 型昇格：有効
- インスタンス / スタティックフィールド: ヒープ上。エイリアスや副作用の温床。 → 型昇格：無効
この境界線を理解していれば、不意にアナライザーから型エラーを突きつけられて迷う時間はゼロになる。コンパイラがなぜその制限を課しているのか、その背後にあるランタイムの安全保障の哲学をコードの隅々にまで行き届かせること――それこそが、真にDartを掌握したアーキテクトの境地である。