【テクニカル・上級編】Hackの『Contravariance』と『Covariance』の完全理解：ジェネリクス型における代入ルールの正体 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

境界を越える型安全：Hackにおける共変・反変の深淵とランタイムの真実

HHVMのコードベースを深掘りしていると、時折「なぜこの型推論は失敗するのか？」という問いに直面する。その答えの多くは、単なる構文ルールではなく、型理論における変位（Variance）の制約にある。

多くの言語が「なんとなく」型システムを運用する中、Hackは `<<__Strict>>` モードを通じて、メモリ安全性を数学的に保証する厳格な代入ルールを課している。今回は、ジェネリクスにおける共変（Covariance）、反変（Contravariance）、そして不変（Invariance）が、HHVMのメモリレイアウトや型チェッカーの挙動にどう影響しているのかを解剖する。

—

1. 型理論の限界：なぜ「継承関係」が「コンテナ」では逆転するのか

まず、基本を再定義しよう。`Animal` クラスを継承した `Dog` クラスがあるとする。このとき、`Dog` は `Animal` のサブタイプである。

しかし、`vec` は `vec` のサブタイプたり得るか？直感に反して、答えは「否」だ。これが変位の難所である。

共変 (Covariance: `+T`)

「読み取り専用」であれば、`vec` を `vec` として扱っても安全だ。`Dog` を取り出したとき、それは間違いなく `Animal` だからである。Hackでは `vec<+T>` のように記述する（実際には `vec` はデフォルトで共変として振る舞う）。

反変 (Contravariance: `-T`)

これは「書き込み専用」の文脈で発生する。`Consumer` があったとき、そこに `Dog` を渡すことは安全だ。つまり、より広義の型を受け入れるものは、狭義の型のコンシューマーとして振る舞える。これが反変だ。

不変 (Invariance)

`darray` やミュータブルなコンテナがこれに該当する。読み取りも書き込みも行う場合、型を完全に一致させなければならない。さもなくば、ランタイムの型安全性が崩壊する。

—

2. なぜ `vec` を `vec` に代入できないのか（HHVM内部事情）

Hackの型チェッカーは、メモリ上のメモリ破壊（Memory Corruption）を未然に防ぐ防壁だ。もし `vec` を `vec` として許可し、そこに `Cat` を挿入できてしまったらどうなるか。

<<__Strict>>
class Animal {}
class Dog extends Animal {}
class Cat extends Animal {}

function unsafe_push(inout vec $animals): void {
// もしコンパイラがこれを許せば…
$animals[] = new Cat();
}

function main(): void {
vec $dogs = vec[new Dog()];
// もし代入が成功すれば、$dogs の中身は [Dog, Cat] となり、
// Dog専用のメソッドを呼び出す際にランタイムセグフォを引き起こす。
unsafe_push(inout $dogs);
}

HHVMのランタイムは、配列のメタデータ内に「何が入っているか」を厳密に追跡している。不変性を強制することで、JITコンパイル時に生成されるマシンコードから型チェックのオーバーヘッドを削除し、驚異的なパフォーマンスを引き出しているのだ。

—

3. 実践：`` と `` の使いこなし

独自のジェネリッククラスを設計する際、`T` にアノテーションを付与することで、型チェッカーの厳格さをコントロールできる。

// 共変: 出力のみ許可
interface IProducer<+T> {
public function produce(): T;
}

// 反変: 入力のみ許可
interface IConsumer<-T> {
public function consume(T $item): void;
}

// 具体例
class Animal {}
class Dog extends Animal {}

class DogProducer implements IProducer {
public function produce(): Dog { return new Dog(); }
}

function feed(IProducer $producer): void {
// 共変のおかげで、IProducer を IProducer として扱える
$animal = $producer.produce();
}

この設計により、HHVMは複雑な型推論を高速に行える。コンパイラは「このクラスは `T` を外部に吐き出すだけである」と判断できれば、内部のメモリ整合性を再計算する必要がないからだ。

—

4. チーフアーキテクトからの助言：型に振り回されるな、型を支配せよ

多くの開発者が陥る罠は、`mixed` や `dynamic` を乱用してこの厳格な型システムから逃避することだ。しかし、それはランタイムの最適化機会を放棄していることに等しい。

1. 不変性をデフォルトとせよ: 迷ったら、まずは不変（Invariance）で定義する。それが最もバグを生みにくい。
2. 共変・反変は境界線で使う: インターフェースや抽象クラスの設計時にのみ、変位アノテーションを活用し、APIの柔軟性を高める。
3. JITとの対話: 型が厳格であればあるほど、HHVMのJITエンジンは型ガードを排除し、直接的なCPU命令を生成できる。厳格な型は、プログラムの「速度」そのものだ。

Hackの型システムは、単なるコーディングの制約ではない。それは、大規模なコードベースにおいて「壊れないソフトウェア」を維持するための、数学的かつ工学的な防壁である。この変位のルールを完全に掌握したとき、貴方の書くコードは、もはやスクリプトではなく、強固な計算機構造物へと昇華されるはずだ。

次は、HHVMの `TypeSpec` とランタイムの型チェックの深淵について話すとしようか。準備はできているか？