【テクニカル・上級編】Hackの『Contravariance（反変）』と『Covariance（共変）』：ジェネリクスにおける型安全な継承のルールを解き明かす – Hack言語 コア・静的型システムとHHVMのアーキテクチャ解析バイブル

—

2. なぜ不変性を破ると「型汚染（Type Confusion）」が発生するのか

もし可変（Mutable）なコンテナに対して共変（`+T`）を許してしまった場合、どのような破滅が訪れるかをメモリレベルでシミュレートしてみよう。

// もし Hack が可変配列（Vector）に対して共変を許してしまったと仮定する（実際は不変）
class Animal {}
class Dog extends Animal { public function bark(): void {} }
class Cat extends Animal {}

function contaminate(Vector $animals): void {
// Animalのコレクションなので、Catを挿入することは仕様上合法
$animals->add(new Cat());
}

function run(): void {
$dogs = Vector { new Dog() };

// もし Vector<+T> が共変であれば、Vector <: Vector となり
// 以下の呼び出しが静的解析をパスしてしまう
contaminate($dogs);

// $dogs の内部メモリ（Heap）の実態は、今や [Dog, Cat] となっている。
// ここでDogとして取り出してメソッドを呼び出すと、実行時にセグメンテーションフォールト
// あるいはHHVM内部のC++キャストエラー（Type Confusion）を引き起こす
foreach ($dogs as $dog) {
$dog->bark(); // Catオブジェクトに対して bark() を呼び出そうとしてクラッシュする！
}
}

HHVMのランタイム（特にJIT領域）において、`$dog->bark()` の実行は、レジスタに格納されたオブジェクトポインタからvtable（仮想関数テーブル）をオフセット参照し、直接コール命令（`CALL`）を発行するアセンブリへとコンパイルされる。

もしここに `Cat` が混入していれば、JITが想定していた `Dog` のクラスレイアウトと異なるオフセットをロードすることになり、最悪の場合、任意コード実行やメモリリークなどの深刻なセキュリティ脆弱性に繋がる。

Hackの静的型チェッカーは、この種のメモリ汚染をコンパイル時（静的解析フェーズ）に100%遮断する。

—

3. 型チェッカーの深部：極性（Polarity）解析アルゴリズム

OCamlで実装されたHack型チェッカー（`hh_server`）は、クラスやインターフェースの定義をパースする際、ジェネリック型パラメータがメソッドのシグネチャ内で現れる位置を走査し、その極性（Polarity）を計算する。

極性は以下のルールで決定される。

• 正の極性（Positive Position / 共変位置）:
• メソッドの戻り値の型。
• 共変インターフェースの型引数。
• 負の極性（Negative Position / 反変位置）:
• メソッドの引数の型。
• 反変インターフェースの型引数。

極性の乗算規則は実数の乗算に酷似している。

$$\text{Positive} \times \text{Positive} = \text{Positive}$$
$$\text{Negative} \times \text{Negative} = \text{Positive}$$
$$\text{Positive} \times \text{Negative} = \text{Negative}$$

例えば、メソッドの「引数の型」の「さらにそのジェネリック引数の型」は、$\text{Negative} \times \text{Negative} = \text{Positive}$（共変位置）となる。

違反検出のメカニズム

型チェッカーは、クラス定義内のすべての型パラメータについて、以下の不変条件（Invariant）を検証する。

1. `+T`（共変アノテーションされた型）は、正の極性（Positive Position）にのみ現れなければならない。
2. `-T`（反変アノテーションされた型）は、負の極性（Negative Position）にのみ現れなければならない。

このルールを破ったコードは、実行環境（HHVM）にロードされる前に、`hh_client` によって即座に拒絶される。

—

4. 極限の実装例：共変と反変の完全な分離

ここでは、実際のシステム開発において、変位を正しく適用してドメインモデルを堅牢にするための極限の実装パターンを示す。

シナリオとして、システム内のイベントストリームを処理する「イベントハンドラ」と、データを読み出す「読み取り専用リポジトリ」を設計する。

<>

abstract class Event {}
class UserCreatedEvent extends Event {}
class AdminCreatedEvent extends UserCreatedEvent {}

/

• 1. 共変インターフェース（Producerの役割）
• 読み取り専用のコンテナ。+T を指定することで、
• IReader は IReader のサブタイプとなる。

/
interface IReader<+TOut> {
// TOut は戻り値（Positive Position）にのみ使用可能
public function getNext(): TOut;
}

/

• 2. 反変インターフェース（Consumerの役割）
• 書き込み/消費専用のハンドラ。-TIn を指定することで、
• IConsumer は IConsumer のサブタイプとなる。
• （＝動物を処理できるハンドラは、犬を処理するハンドラとして安全に扱える）

/
interface IConsumer<-TIn> {
// TIn はメソッド引数（Negative Position）にのみ使用可能
public function consume(TIn $input): void;
}

/

• 具象実装クラス

/
class EventReader implements IReader {
public function getNext(): AdminCreatedEvent {
return new AdminCreatedEvent();
}
}

class UserEventHandler implements IConsumer {
public function consume(UserCreatedEvent $event): void {
// ユーザー作成イベントに対する処理
echo “Processing user event…\n”;
}
}

/

• 実行コンテキストにおける変位の検証

/
function processReader(IReader $reader): void {
// IReader は IReader のサブタイプとして適合する（共変）
$event = $reader->getNext();
echo “Retrieved event: ” . get_class($event) . “\n”;
}

function registerConsumer(IConsumer $consumer): void {
// IConsumer は IConsumer のサブタイプとして適合する（反変）
// なぜなら、UserCreatedEventを処理できるコンシューマは、その派生であるAdminCreatedEventも安全に処理できるからである。
$event = new AdminCreatedEvent();
$consumer->consume($event);
}

<<__EntryPoint>>
function main(): void {
$reader = new EventReader();
processReader($reader); // 共変性による安全な代入

$consumer = new UserEventHandler();
registerConsumer($consumer); // 反変性による安全な代入

echo “Verification Success.\n”;
}

コード解説

• `IReader<+TOut>`: `getNext()` の戻り値として `TOut` を返す。これは共変（Positive）であるため、`IReader` は `IReader` として振る舞うことができる。
• `IConsumer<-TIn>`: `consume(TIn $input)` の引数として `TIn` を受け取る。これは反変（Negative）であるため、`IConsumer` は `IConsumer` にキャスト可能となる。
• 型チェッカーはこの関係性を厳密に検証し、もし `IConsumer` に `public function getLatest(): TIn` のようなメソッド（NegativeパラメータをPositive位置で返す）を追加しようとすれば、コンパイルエラーを発生させる。

—

5. HHVM JITコンパイラと変位がもたらす「超高速化」の内部機序

Hackにおける変位アノテーションは、単なるプログラマのバグ防止ツールに留まらない。HHVMの実行エンジン、特に JIT（Just-In-Time）コンパイラ にとって、これはコード最適化のための強力なヒントとなる。

ガードオプティマイザ（Guard Optimization）への寄与

HHVMは、実行時のプロファイリング情報に基づいて、動的な型チェックを最適化されたアセンブリコードへと変換する。

通常、ジェネリクスが絡むオブジェクトの操作では、ランタイムは対象オブジェクトが本当に想定された型階層に属しているかをチェックする「ガード条件（Guard Operations）」を挿入する。

ガード条件の擬似アセンブリ
test_type_rdi:
movq (%rdi), %rax # オブジェクトのクラスワードをロード
movq $ExpectedClass, %rbx
cmpq %rbx, %rax
jne .mismatch_handler # 型が不一致ならJITサイドイグジット（低速パス）へ

しかし、静的型システムで型パラメータの変位（共変/反変）が100%保証されている場合、HHVMのJIT内の SSA（Static Single Assignment）ベースの中間表現（IR） は以下のように最適化される。

1. Devirtualization（脱仮想化）:
共変インターフェース `IReader<+T>` から取得されたオブジェクトは、静的に `T` のサブタイプであることが保証されている。これにより、JITは呼び出し先メソッドのターゲットを絞り込み、間接コール（`call %rax`）を直接ジャンプ（`jmp` または `call`）へとインライン化できる。
2. Type Propagation（型伝播によるガード削減）:
反変インターフェース `IConsumer<-T>` に渡されるオブジェクトは、静的型チェッカーによってすでにダウンキャストが保証されているため、メソッド境界を越える際に行われるランタイムの `assert` や `verify_type` 命令が完全にバイパス（デッドコード除去）される。

結果として、変位を厳格に定義することは、「ランタイムのチェックコストを最小化し、C++と同等のネイティブコードを生成する」ための必須要件となっている。

—

6. まとめ

Hackにおける共変（`+`）と反変（`-`）は、型理論の美しさを実用言語の極限まで落とし込んだ傑作である。

• 共変（`+T`）は出力（読み取り専用）を安全にし、サブタイプ関係を順方向に維持する。
• 反変（`-T`）は入力（書き込み専用）を安全にし、サブタイプ関係を逆転させる。
• これらの制約は、OCamlベースの高速な型チェッカーが極性解析によって静的に保証する。
• HHVM JITは、この静的保証を信頼してガード条件を排除し、最高峰の実行パフォーマンスを叩き出す。

この変位のルールを完全に脳内にトレースし、設計に組み込むこと。それこそが、HHVMという怪物を真に手懐け、大規模かつ堅牢なシステムを構築するためのシステムアーキテクトの条件である。