Phantom Typesによるコンパイル時の状態保証：型システムでビジネスルールを表現する
HHVM（HipHop Virtual Machine）のアーキテクチャ、そしてHack言語の静的型チェッカーの内部挙動を極限まで理解している者であれば、型とは単なる「データの入れ物のラベル」ではないことを知っているはずだ。型とは、ランタイムのオーバーヘッドをゼロにしつつ、プログラムの安全性をコンパイル時に証明するための形式論理の証明器である。
今回は、Hackの厳格なモード（`<<____EntryPoint>>` および `STRICT` モード）を極限まで押し上げ、実行時チェックという名の「惰性」を排除するPhantom Types（幻影型）による状態保証の設計論を解説する。
—
1. なぜランタイムチェックは悪なのか：HHVMと型チェッカーの視点
Webアプリケーション開発において、「このユーザーは認証されているか？」「この注文は決済済みか？」といった状態遷移の検証は避けて通れない。多くのプログラマは、これを以下のような防御的コードで実装する。
<<__EntryPoint>>
function process_order(Order $order): void {
if (!$order->isPaid()) {
throw new UnpaidOrderException(“Paid order required.”);
}
// ビジネスロジック
}
このアプローチには2つの致命的な問題がある。
1. 認知負荷と漏れ: 開発者は「このメソッドを呼ぶ前にチェックしたか」を常に記憶し続けなければならない。チェック漏れは本番環境のクラッシュやセキュリティインシデント直結する。
2. ランタイムコスト: HHVMのJITコンパイラ（RepoAuthoritativeモードなど）がいかに最適化しようとも、条件分岐（`if`）や例外機構のハンドリングはCPUパイプラインを乱し、わずかではあるが確実にスループットを低下させる。
型チェッカーによるゼロコスト・エンフォースメント
Hackの型チェッカー（`hh_client` / `hh_server`）は、静的解析の段階でAST（抽象構文木）を走査し、すべての式の型関係を検証する。もし、「状態そのものを型に内包させ、不正な状態のオブジェクトをメソッドに渡すこと自体を構文エラーにする」ことができたらどうだろうか？
これがPhantom Typesの本質である。ランタイムには一切のオーバーヘッドを残さず、バイトコード生成の段階で安全性を完全に担保する。
—
2. HackにおけるPhantom Typesの実装パターン
Phantom Typesとは、データ構造自体には保持されないが、型パラメータ（Generics）としてのみ存在する型（マーカー型）を利用して、型の直交性を強制する技法である。
以下のコードは、ECサイトにおける「カート（Cart）」の状態遷移を、Hackの厳格な型システムで完全に制御する実装例である。
namespace Hack\Advanced\PhantomTypes;
// — 1. 状態を表すマーカー型（インスタンス化されることはない） —
interface CartState {}
final class EmptyCart implements CartState {}
final class ActiveCart implements CartState {}
final class CheckedOutCart implements CartState {}
// — 2. Phantom Typeを持つジェネリックなカートクラス —
// ここで TRState が Phantom Type。クラス内のプロパティとしては保持されない。
final class Cart
private vec
// 外部からの直接インスタンス化を禁じ、ファクトリ経由にする
private function __construct() {}
public static function create(): Cart
return new Cart();
}
// EmptyCart から ActiveCart への遷移
public function addItem(string $item): Cart
$new_cart = new Cart();
// 既存のアイテムを引き継ぐ（イミュータブルな設計）
$new_cart->items = Vec\concat($this->items, vec[$item]);
return $new_cart;
}
// ActiveCart のみマンデートされる決済処理
public function checkout(this
// 決済ゲートウェイとの通信（省略）
$new_cart = new Cart();
$new_cart->items = $this->items;
// HHVMの最適化を阻害しないシームレスな型トランスフォーメーション
return $new_cart;
}
public function getItems(): vec
return $this->items;
}
}
この設計のキモ：`this $this`
Hack言語特有の強力な機能として、`this
`checkout` メソッドのシグネチャに注目してほしい。
public function checkout(this
これにより、「このメソッドは、`Cart
—
3. クライアントコードの振る舞いとコンパイルエラーの検証
では、このPhantom Cartを使ったクライアント側のコードを見てみよう。
<<__EntryPoint>>
function main(): void {
// 1. カートを生成 (Cart
$cart = Cart::create();
// 2. アイテムを追加 (Cart
$active_cart = $cart->addItem(“Hack Programming Guide”);
// 3. 決済を実行 (Cart
$paid_cart = $active_cart->checkout();
// 【コンパイルエラーになる例】
// 空のカートのまま直接決済しようとする
// $invalid_cart = Cart::create()->checkout();
//
// HH_ERROR: Invalid argument
// Expected `Cart
// it’s an unpopulated cart.
}
コメントアウトされた不正なコード：
Cart::create()->checkout();
これは、HHVMのバイトコードジェネレータに到達するはるか手前、開発者のエディタ上（LSP経由）またはCIの `hh_server` 実行時に完全に弾かれる。ランタイムでの条件分岐（`if (!empty)` など）を書く必要は一切ない。CPUキャッシュを汚す分岐予測ミス（Branch Misprediction）のコストすらゼロになるのだ。
—
4. HHVMのバイトコード最適化（RepoAuthoritativeモード）との親和性
シニアエンジニアとして、これがHHVMの実行モデルにどう影響するかを言及しておかねばならない。
HHVMが最高パフォーマンスを発揮するのは、RepoAuthoritativeモード（ソースコードを静的にコンパイルし、すべての型情報をバイトコードに焼き付けて実行するモード）の時である。
Phantom Typesによって記述されたコードは、以下の利点を持つ。
1. デモート（Demotion）のない厳格な型:
Hackの `strict` モードでは、すべての関数とメソッドで引数と戻り値の型が完全に解決されている必要がある。Phantom Typesを用いることで、メソッドディスパッチ時に動的な型チェック（`instanceof` のようなランタイムオーバーヘッド）を行う必要がなくなり、HHVMはダイナミックディスパッチを直接的な関数呼び出しやインライン展開（Inlining）へ最適化しやすくなる。
2. メモリレイアウトの予測可能性:
イミュータブルな状態遷移と組み合わせることで、オブジェクトのライフサイクルが単方向（DAG: 有向非巡回グラフ）になり、HHVMのガベージコレクタ（Ref-countingベース）における負荷を最小化できる。不要になった古い状態のインスタンスは即座に解放の対象となる。
—
結言：型を「制約」ではなく「言語表現」へ
多くのプログラマは、型をエラーを防ぐための「足かせ」だと勘違いしている。しかし、Phantom Typesをマスターしたエンジニアにとって、型とは「ビジネスドメインのルールをバグの入り込む余地なく記述するための最高峰のプログラミング言語」に他ならない。
Hackの圧倒的な静的解析能力と、HHVMの怪物的な実行性能が交差する領域において、Phantom Typesはあなたのコードベースを「絶対に壊れない要塞」へと変貌させる。
明日からの設計に、ランタイムチェックの排除と型レベルの状態機械（State Machine）を導入せよ。妥協のないコードだけが、極限のスケールを生き抜くことができる。