Hack言語におけるVariance（変性）の極限解体：型安全性とHHVMランタイムの境界線
HHVM（HipHop Virtual Machine）のコアエンジニアリングチームにおいて、我々が常に直面してきた最大の課題は、「動的言語の柔軟性」と「静的解析の厳格さ」の極限的な調和である。Hack言語はその黎明期から、PHPの遺産である動的バグの温床を根絶するため、妥協なき静的型システムを構築してきた。
その型システムの中核でありながら、多くのシニアエンジニアですら深淵で足をすくわれる概念が Variance（変性：共変・反変・非変） である。
本稿では、Hackにおけるジェネリクスと変性の数学的・機械的基礎を解き明かし、HHVMのJITコンパイラや型チェッカーがどのようにこれらを処理し、メモリ安全性とパフォーマンスを担保しているのかを、実戦的なコードと共に徹底解説する。
—
1. 変性（Variance）とは何か：型システムの幾何学
ジェネリック型（例: `Vector
基底型 `Animal` と、その派生型 `Dog` が存在すると仮定する。この時、`Dog` は `Animal` の代わりとして機能し得ること（Liskovの置換原則：LSP）は自明だ。しかし、これをジェネリック型に適用した瞬間、直感が裏切られる。
HackのStrict Mode（`<
1. 非変（Invariant）: パラメータ型が完全に一致していなければならない（Hackのデフォルト）。
2. 共変（Covariant / `+`）: サブタイプの関係をそのまま維持する（読み出し専用）。
3. 反変（Contravariant / `-`）: サブタイプの関係を逆転させる（書き込み専用）。
—
2. Hackにおける変性の構文と実用パターン
Hackでは、インターフェイスやベクターの型定義において、プレフィックス `+`（共変）および `-`（反変）を用いて変性を指定する。
以下のコードは、読み取り専用のデータソースにおける共変と、書き込み専用のコンシューマにおける反変を実装した実戦的なパターンである。
<
namespace Hack\Engine\Variance;
// — 基底と派生クラス —
abstract class Entity {}
<<__ConsistentConstruct>>
final class Player extends Entity {
public function __construct(public string $name) {}
}
// — 1. 共変（Covariant: +T）の定義 —
// データの「生産（Producer）」にのみ使用される。つまり戻り値型としてのみ登場する。
interface IProducer<<__Covariant+T>> {
public function produce(): T;
}
final class PlayerProducer implements IProducer
public function __construct(private Player $player) {}
public function produce(): Player {
return $this->player;
}
}
// — 2. 反変（Contravariant: -T）の定義 —
// データの「消費（Consumer）」にのみ使用される。つまり引数型としてのみ登場する。
interface IConsumer<<__Contravariant-T>> {
public function consume(T $entity): void;
}
final class EntityConsumer implements IConsumer
public function consume(Entity $entity): void {
\printf(“Consumed entity of type: %s\n”, \get_class($entity));
}
}
なぜ共変は「読み出し専用」でなければならないのか？
もし共変なコンテナに対して「書き込み（代入）」を許可すると、型安全性が完全に崩壊する。
// 思考実験：もし Vector<+T> が書き込み可能だったら？
// IProducer
// 外部から Cat（Animalの別の子孫）を突っ込まれた瞬間、中身は Player のつもりだったコードがクラッシュする。
HHVMの型チェッカー（`hh_client`）は、共変な型パラメータがメソッドの「引数位置（Contravariant position）」に出現した瞬間、容赦なくコンパイルエラーを吐き出す。同様に、反変な型パラメータが戻り値位置に出現することも禁止されている。このルールは「安全性のための鉄則」である。
—
3. HHVMアーキテクチャから見たジェネリクスとメモリの現実
ここで一層レイヤを下げ、HHVMのランタイム内部におけるジェネリクスの表現について触れておく必要がある。
PHP/Hackの実行基盤であるHHVMは、JITコンパイラ（Region Engine / LLVMベースの翻訳レイヤ）を備えている。ジェネリッククラスは、C++のテンプレートのように静的にコードが展開されるわけではない（Reticule型消去モデルに近い挙動をとる）。
1. タイプの具象化（Reification）と代入互換性
Hackでは `<<__Reified>>` 属性を用いることで、実行時（Runtime）においても型パラメータの情報を保持できる。しかし、通常のジェネリクスや変性を持つインターフェイスは、ランタイムの型チェックコストを最小限に抑えるため、型チェッカーが静的にその安全性を保証する。
<
interface IProcessor<<__Covariant+TOut, __Contravariant-TIn>> {
public function process(TIn $in): TOut;
}
このような「入出力双方が混在する型」を設計する場合、単純な共変・反変の適用は不可能であり、型パラメータごとに変性を分離して設計する必要がある。これが不十分な設計は、HHVMのJIT最適化フェーズにおいて、型ガード（Type Guards）のインライン展開を阻害し、ボックス化（Boxing）されたプリミティブの多発によるメモリプレッシャーを引き起こす。
2. メモリ最適化とVtablesの構造
HHVMのオブジェクトモデルにおいて、メソッド呼び出しはVtable（仮想メソッドテーブル）を介して行われる。共変・反変が適切に型レベルで保証されているおかげで、HHVMはダウンキャストや実行時の `is` チェックを極限まで削減できる。
もし変性を無視して動的な型アサーションを多用すると、JITはネイティブマシン語へのコンパイルを諦め、インタープリタへのフォールバック（Slow Path）が発生する。これは高スループットを要求される大規模Webアプリケーションにおいて致命的なレイテンシの増加を招く。
—
4. 現場で遭遇する型エラーの克服とアンチパターン
最後に、大規模コードベースのリファクタリング時によく遭遇する「変性に起因するエラー」の回避策を提示する。
アンチパターン：不必要な非変（Invariant）の放置
デフォルトのジェネリクス（例: `class Box
<
class Box
function processBox(Box
// 以下のコードは Box
// function run(Box
// processBox($pBox);
// }
解決策：適切な変性注釈の付与
もし `Box` がデータを保持するだけでイミュータブル（不変）な構造体なのであれば、共変 `<<__Covariant+T>>` を付与すべきである。
<
// イミュータブルなコンテナとしての設計
class ImmutableBox<<__Covariant+T>> {
public function __init(private T $value) {}
public function get(): T {
return $this->$value;
}
}
この変更により、`ImmutableBox
—
5. 結びにかえて
Hack言語の厳格な静的型システム（Strict Mode）と変性の概念は、単なるアカデミックな理論の遊戯ではない。それは、数百万行規模のコードベースにおいて、実行時エラーをコンパイル時に完全に駆逐し、HHVMのJITエンジンから限界までパフォーマンスを引き出すための「エンジニアリングの武器」である。
型チェッカーが鳴らすエラー音を敵とみなすな。それは、君のコードがシステムにより深く、より安全に最適化されている証左なのだから。