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

Hackを掌握する極限の知見：ジェネリクスにおける変位指定（Variance）の深淵

HHVM（HipHop Virtual Machine）のアーキテクチャとHackの厳格な型システムにおいて、型の安全性は単なるコンパイル時の気休めではない。それはランタイムの最適化、JITコンパイルにおける型推論の精度、そしてゼロコスト抽象化の基盤そのものである。

特に `strict` モードにおけるジェネリクスの変位指定（Variance：共変性 `covary` / 反変性 `contravary`）は、不完全な理解のまま実装すれば、ランタイムの型安全性を揺るがすか、あるいは不毛なボイラープレートの海に沈む原因となる。

本稿では、Hackの型チェッカー（typechecker）が内部でどのようにジェネリックな型関係を解決しているのか、そしてHHVMのオブジェクトモデルにおいて変位がどのように作用するのかを、極限の低レイヤ視点から解き明かす。

—

1. 変位指定の本質：なぜ `Base` を `Base` に代入できないのか？

プログラミング言語の初学者が最初に直面する壁が、「サブタイプの関係にあるクラス群を包むジェネリック型が、なぜそのままサブタイプ関係を引き継がないのか」という疑問だ。

例えば、以下のようなクラス階層を考える。

<<__EnforceMutable>>
class Animal {}
class Dog extends Animal {}

ここで、`IProducer` というインターフェイスを定義する。

interface IProducer {
function get(): T;
}

直感的には、`Dog` は `Animal` のサブなのだから、`IProducer` も `IProducer` のサブタイプであってほしい。しかし、デフォルトの不変（Invariant）な世界では、これは型エラーになる。なぜなら、もし不変性が強制されない場合、以下のような型安全性の崩壊（Liskovの置換原則の違反）が起きるからだ。

// 擬似的な危険なコードの思考実験
IProducer dogProducer = / … /;
IProducer animalProducer = dogProducer; // もしこれが許容されたら…
Animal animal = animalProducer.get(); // 実際にはCatが返ってくるかもしれない！

HHVMの仮想マシンレイヤおよびHackの静的解析器は、この種の型汚染をコンパイルアット・オンス（compile-at-once）の段階で完全に遮断しなければならない。ここで登場するのが、共変性（Covariance: `<<__Covariant>>`）と反変性（Contravariance: `<<__Contravariant>>`）である。

—

2. 共変性（``）のメカニズムと出力の位置（Output Position）

共変性は、「より具体的な型（Dog）から、より抽象的な型（Animal）への方向性」を型引数に許容する仕組みである。Hackでは `+` プレフィックス、あるいはアノテーション `<<__Covariant>>` を用いて指定する。

共変な型パラメータは、「生産者（Producer）」、すなわちメソッドの戻り値の型（出力の位置）にのみ使用できる。メソッドの引数（入力の位置）に共変な型パラメータを配置することは、型チェッカーによって厳格に禁止される。

実装例：共変インターフェイス

<>
namespace Hack\DeepDive;

class Animal {}
class Dog extends Animal {
public function bark(): void {
echo “Woof!\n”;
}
}

// 共変インターフェイスの定義
// T は「読み出し専用」として振る舞う
interface IReadonlyBox<<__Covariant T>> {
public function get(): T;
}

class DogBox implements IReadonlyBox {
private Dog $dog;

public function __construct(Dog $dog) {
$this->$dog = $dog;
}

public function get(): Dog {
return $this->$dog;
}
}

function processAnimals(IReadonlyBox $box): void {
// IReadonlyBox を IReadonlyBox として安全に受け取れる
$animal = $box->get();
// ランタイムにおいてメモリ構造のキャストは不要であり、
// HHVMのポインタはそのまま安全にルーティングされる。
}

<<__EntryPoint>>
function main(): void {
$dogBox = new DogBox(new Dog());
processAnimals($dogBox); // 型安全に通過する
}

HHVMのメモリ最適化と共変性

HHVMのオブジェクトモデルにおいて、オブジェクト参照は統一されたポインタサイズ（64bitアーキテクチャでは8バイト）を持つ。共変性が保証されている場合、型チェッカーは「呼び出し元が期待する基底クラスのインターフェイス」と「実際の具象クラスのvtable（仮想メソッドテーブル）」の整合性を静的に保証するため、ランタイム側で動的な型チェック（`instanceof` の多用など）を行う必要がなくなる。これにより、JITコンパイラは型ガードを排除し、インラインキャッシュのヒット率を極限まで高めることができる。

—

3. 反変性（``）のメカニズムと入力の位置（Input Position）

反変性は共変性の逆であり、「より抽象的な型（Animal）から、より具体的な型（Dog）への方向性」を型引数に許容する。Hackでは `-` プレフィックス、あるいは `<<__Contravariant>>` で指定する。

反変な型パラメータは、「消費者（Consumer）」、すなわちメソッドの引数の型（入力の位置）にのみ使用できる。

実装例：反変インターフェイス

<>
namespace Hack\DeepDive;

interface IConsumer<<__Contravariant T>> {
public function consume(T $item): void;
}

class AnimalPrinter implements IConsumer {
public function consume(Animal $item): void {
echo “Consuming an animal safely.\n”;
}
}

function handleDogEvents(IConsumer $consumer): void {
// IConsumer は IConsumer の代わりとして使える！
// なぜなら、Dogを処理できる能力を持つ者は、当然より広範なAnimalも処理できるからだ。
$consumer->consume(new Dog());
}

<<__EntryPoint>>
function main(): void {
$animalPrinter = new AnimalPrinter();
handleDogEvents($animalPrinter); // 型安全に通過する
}

なぜ引数は反変なのか？（直感の逆を行く理由）

多くのエンジニアが混乱するのはここだ。「`Dog` を受け取る関数に、なぜ `Animal` を受け取る消費者を渡せるのか？」
答えは 「能力の包含関係」 にある。
`IConsumer` は、「どんな動物（Animal）が来ても処理できる」という普遍的なコントラクトを持っている。したがって、システムが急に「`Dog` をくれ」と要求したとき、`IConsumer` を渡せば、彼は喜んで `Dog`（それはAnimalの一種である）を処理できる。
逆に、`IConsumer` に `Animal`（例えばCatかもしれない）を渡したらシステムが崩壊する。ゆえに、要求されるスコープに対して、より広範囲を処理できる「抽象的な消費者」を渡すことが安全なのである。この論理構造が、反変性の数学的根拠である。

—

4. 不変（Invariant）、共変（Covariant）、反変（Contravariant）のまとめ

—

5. 高度な応用：関数型インターフェイスにおける変位の調和

大規模なドメイン駆動設計（DDD）や、関数型パラダイムをHackに持ち込む際、最も強力な武器となるのが「高階関数と変位指定の組み合わせ」である。
例えば、マッパー（Mapper）や関数型インターフェイスを定義する場合、入力は反変、出力は共変にする必要がある。

<>
namespace Hack\DeepDive;

// 関数型インターフェイス：入力に対して共変・反変を同時に持つ
interface IFunction<<__Contravariant TIn, __Covariant TOut>> {
public function invoke(TIn $input): TOut;
}

この設計により、例えば「`Animal` を受け取り `Dog` を返す関数」が必要な箇所に、「`Dog` を受け取り `Animal` を返す関数」や、さらに抽象化された関数を、型チェッカーの完全な庇護のもとで差し替えることが可能になる。

—

結言：型チェッカーを敵に回すな、味方に付けろ

Hackの `strict` モードにおける変位指定は、動的言語出身の開発者にとっては足かせのように映るかもしれない。しかし、それはHHVMのランタイムパフォーマンスを極限まで引き出し、大規模コードベースにおけるリファクタリングの恐怖を消し去るための「究極の防壁」である。

共変と反変の方向性を完全に脳内でルーティン化し、メソッドのシグネチャを設計すること。それこそが、世界最高峰のHackコードベースを構築するチーフアーキテクトに求められる必須のスキルなのである。