Hackの型推論エンジンが辿るパス：型チェッカーが変数を特定するまでの内部アルゴリズム
コードレビューを始めてくれ。お前らが普段何気なく書いているそのHackのコード、本当に型チェッカーの心を理解して書けているか？
「とりあえず `mixed` を避けて `strict` にしておけば安全」——そんな甘い認識でプロダクションコードを汚染しているなら、今日で終わりだ。
我々が扱うHack言語の真価は、単なるPHPの亜種ではない。HHVM（HipHop Virtual Machine）のJITコンパイラと強固に結合した厳格な静的型システム（Strict Mode）こそがその心臓部だ。しかし、型チェッカー（hh_client / hh_server）がどのようにコードをスキャンし、AST（抽象構文木）を舐め回し、変数の型を特定しているか、その内部アルゴリズムの挙動まで正確に理解しているエンジニアは驚くほど少ない。
今日は、Hackの型推論エンジンが辿るパスの深淵を覗き、バグの入り込む余地を完全にコンパイル時に焼き払うための「極限の設計パターン」を伝授する。
—
1. 型チェッカーの内部アルゴリズム：制約生成から型推論（Constraint-based Type Inference）への旅
HHVMの型チェッカーは、ソースコードをパースしてASTを生成した後、Hindley-Milner系をベースにした制約ベースの型推論（Constraint-based Type Inference）アルゴリズムを実行する。
内部では大きく分けて以下の3つのフェーズを駆け抜けている。
1. スコープとシンボル解決（Name Binding）
クラス、関数、インターフェースの依存関係グラフをメモリ上に構築し、名前空間を解決する。この段階で、`use` 文の整合性やオートローディングの境界が定まる。
2. 制約の生成（Constraint Generation）
コードの各文（Statement）や式（Expression）を走査し、「この変数はこの操作が行われるため、型 $T$ のサブタイプでなければならない」という数学的な制約（Constraints）の不等式を次々と生成していく。
3. 単一化（Unification）と解決（Solving）
生成された制約の集合をグラフ理論を用いて解く。ここで矛盾が生じれば、お馴染みのエラーコード（例: `HH(1002)` など）がコンソールに叩きつけられる。
なぜ「動的な再代入」が型推論を殺すのか？
型チェッカーの最大の敵は、「スコープ内での型の変質」だ。
// 【アンチパターン】型推論エンジンを混乱させる悪夢
function process_data(bool $condition): array
$data = “”; // ここで $data は string と推論される
if ($condition) {
$data = vec[1, 2, 3]; // 突然のvec
}
// この時点で $data は string | vec
return $data;
}
このようなコードを書くと、型チェッカーは不必要なユニオン型の解決コストを支払い、JITコンパイラも最適化のパスを失う。HHVMのパフォーマンスを極限まで引き出したいなら、変数は常にイミュータブル（不変）に近く、代入の時点で型が完全に確定している状態を強制しなければならない。
—
2. 現場で使える！堅牢なプロダクションコード設計パターン
非同期API連携や複雑なドメインロジックを扱うWebシステムにおいて、型安全性を極限まで高めつつ、ボイラープレートを排除した美しい実装パターンを示そう。
以下のコードは、型チェッカーの推論アルゴリズムを完全に手玉に取り、実行時エラーをコンパイル時に100%封殺するジェネリック・リポジトリパターンの実装だ。
namespace App\Repository;
type QueryParameters = dict
interface IEntity {
public static function fromRow(dict
}
/
- 型推論エンジンを完璧に誘導する抽象データローダー
- @template T as IEntity
/
abstract class BaseRepository
require extends \App\Core\DatabaseConnection;
/
- 指定されたIDに基づいて厳格に型付けられたエンティティを返す。
- 戻り値の型が呼び出し元で完璧に推論されるため、キャストは一切不要。
/
final public async Awaitable findByIdAsync(int $id): Awaitable {
// SQLクエリの実行（擬似コード）
$row = await $this->queryRowAsync(
“SELECT FROM ” . static::getTableName() . ” WHERE id = ?”,
vec[$id]
);
if ($row === null) {
return null;
}
// クラス名を表す static::class を用いることで、
// 具象クラスの fromRow が確実に呼ばれることを型チェッカーに保証させる
return T::fromRow($row);
}
abstract protected static function getTableName(): string;
}
/
- 具象エンティティ：User
/
final class User implements IEntity {
public function __construct(
public int $id,
public string $email,
) {}
public static function fromRow(dict
// 厳格なキー存在チェックと型アサーション
invariant(
Shapes::idx($row, ‘id’) is int && Shapes::idx($row, ‘email’) is string,
‘Database schema mismatch for User entity.’
);
return new static(
(int)$row[‘id’],
(string)$row[‘email’]
);
}
}
final class UserRepository extends BaseRepository
protected static function getTableName(): string {
return ‘users’;
}
}
このコードが美しい理由（テックリードからの解説）
1. `this` 型と `class` の協調
`IEntity::fromRow` の戻り値に `this`（Late Static Bindingに対応する型）を使用し、さらにジェネリクス制約 `
2. `invariant` によるスマートな型ガード
PHPの泥臭い `is_int()` チェックの代わりに、Hackの `is` 演算子と `invariant` を組み合わせることで、型チェッカーに対し「この行を通過した時点で変数はこの型である」という追加の制約（Flow Typingの拡張）を明示的に教え込んでいる。
—
3. パフォーマンス上の注意点：型チェッカーを疲弊させるな
大規模なモノリスリポジトリになってくると、`hh_server` のメモリ消費量増大や、型チェックのレスポンス低下（いわゆる「重い」状態）に直面する。これは大抵、以下のアンチパターンが原因だ。
- 過度な複雑性を持つネストされたUnion型とShape
不必要に巨大な `shape(…)` や複雑なジェネリクスのネストは、単一化フェーズにおける状態空間を爆発的に増殖させる。型チェッカーのCPU使用率が100%に張り付く原因の筆頭だ。
- `mixed` や `dynamic` への安易な逃避
「面倒だから」と `mixed` で受けて `is` でガードするコードを乱発すると、型チェッカーは推論を諦め、ランタイムに近いオーバーヘッドを静的解析フェーズに持ち込むことになる。
対策：型エイリアス（Type Aliases）で境界を明確化せよ
複雑なデータ構造は、必ずトップレベルの `type` または `newtype` で名前を付け、型チェッカーが効率的にキャッシュできるようにスコーピングを絞れ。
// 良い例：複雑な構造には必ず型エイリアスを付与し、推論の単位をモジュール化する
type UserPayload = shape(
‘id’ => int,
‘profile’ => shape(
‘name’ => string,
‘tags’ => vec
),
);
—
結びにかえて
Hackの型チェッカーは単なる「エラー発見器」ではない。お前らが書いたコードの意図を汲み取り、HHVMのJIT最適化のための設計図を裏で構築している極めて高度なパートナーだ。
型チェッカーのアルゴリズムを脳内にトレースし、「今、チェッカーはこの変数にどんな制約を課しているか？」を意識できるようになれば、お前の書くコードからバグは完全に駆逐される。
さあ、エディタを開け。妥協のない、美しい厳格型の世界へ戻るんだ。