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

型の崩壊を許さない：Hackのジェネリクスにおける変位（Variance）の深淵

Hackの型システムは、単なる「静的チェックの補助輪」ではない。HHVMという極めて高速な実行エンジン上で、メモリ安全性を担保しつつ、JITコンパイルの最適化を最大化するための「制約の言語」だ。

特に、ジェネリクスにおける変位（Variance）—共変（Covariance）と反変（Contravariance）—を理解することは、Hackの型チェッカーをハックするに等しい。多くのエンジニアがここで直感的な誤解をし、ランタイムエラーの温床を作る。今日はその正体を、コンパイラの裏側から解き明かす。

—

1. なぜ「代入」が型安全性を破壊するのか

まず、基本的な問いを立てよう。`Vector` は `Vector` に代入可能か？

直感的にはYESだ。「犬は動物だから、犬のリストは動物のリストとして扱えるだろう」。だが、型理論的にこの直感は危険な罠である。もし `Vector` として扱えたなら、そのリストに `Cat` を追加できてしまう。結果、`Vector` の中に `Cat` が混入し、実行時にメモリ破壊やメソッド呼び出しの不整合を引き起こす。

HackのStrict Modeは、この「読み込み」と「書き込み」の非対称性を厳格に管理する。

—

2. 変位の理論的定義とHHVMの戦略

Hackのジェネリクスにおいて、変位は「型の包含関係を維持するか、反転させるか」を決めるルールだ。

共変（Covariance）：`+T`

ルール: `Container` は `Container` のサブタイプとして扱える。
制約: このコンテナは「読み込み専用（Producer）」でなければならない。
HHVMの視点: JITコンパイラは、コンテナが不変であることを前提に、型ガードを省略し、レジスタへのロードを最適化できる。

反変（Contravariance）：`-T`

ルール: `Consumer` は `Consumer` のサブタイプとして扱える。
制約: このコンテナは「書き込み専用（Consumer）」でなければならない。
HHVMの視点: 引数として受け取る型が汎化されているため、メソッド呼び出しのディスパッチにおいて、より広いインターフェースを利用した動的最適化が可能になる。

—

3. 実践：Hackにおける実装パターン

Hackでは、インターフェースやクラスの定義で変位を指定できる。以下に、安全な設計の極意を示す。

namespace HackDeepDive;

interface Producer<+T> {
// 共変: Tを戻り値として返すことはできるが、引数として受け取ることはできない
public function produce(): T;
}

interface Consumer<-T> {
// 反変: Tを引数として受け取ることはできるが、戻り値として返すことはできない
public function consume(T $item): void;
}

class Animal {}
class Dog extends Animal {}

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

function processAnimals(Producer $producer): void {
// DogProducerはProducerに代入可能（共変性）
$animal = $producer->produce();
}

このコードの肝は、コンパイラが「書き込み」の試みを静的に拒絶する点にある。もし `Producer<+T>` のメソッド引数に `T` を指定しようとすれば、Hackコンパイラは即座にエラーを吐く。これはランタイムのメモリ安全性を守るための「物理法則」だ。

—

4. メモリレイアウトと型消去の先にあるもの

HHVMは実行時にジェネリクスの情報を部分的に消去（Type Erasure）するが、Strict Modeで定義された変位は、コンパイル時のアサーションとして機能し、JITが生成するマシンコードの「信頼性」を保証する。

もし変位のルールを無視したコードを無理やり通そうとすれば、HHVMは型チェックで落ちるか、あるいは型不整合による未定義挙動を避けるために過剰なチェックコードを挿入することになる。これはパフォーマンスにとって致命的だ。

上級者への提言：
ジェネリクスを設計する際は、その型が「データを供給する側（Producer）」なのか「データを受け取る側（Consumer）」なのかを厳密に分離せよ。双方向性が必要な場合は、変位を使わずに不変（Invariant）のままにしておくのが、最もパフォーマンスが高く、かつコードの意図が明確になる。

—

5. 結論：型は「守り」ではなく「攻撃的な設計」である

Hackの型システムをマスターするとは、コンパイラに対して「どのメモリ領域が安全で、どの操作が許容されるか」という境界線を明確に指示することだ。

共変・反変は、単なる言語仕様のパズルではない。スケーラブルなシステムにおいて、疎結合を保ちつつ、型安全性を犠牲にしないための最強の武器である。この変位の概念を脳内にインストールすれば、君が書くHackコードは、HHVMの力を最大限に引き出す最適化されたマシンコードへと昇華されるだろう。

次は、`Type Structure` と `Reified Generics` を組み合わせた、ランタイム型チェックの極限を議論しよう。Hackの深淵はまだ入り口に過ぎない。