【上級者向け】共変（Covariance）と反変（Contravariance）の完全理解：ジェネリクス型における代入ルールの正体
HHVMのコアを統括するアーキテクトとして、日頃から多くのコードベースを見てきたが、依然としてシニアエンジニアクラスの開発者であっても、ジェネリクスの変性（Variance）に起因する型エラーに直面した際に行き当たりばったりで修正を試みるケースが後を絶たない。
`Type mismatch` に直面したとき、反射的にアノテーションを書き換えるのではなく、Hackの厳格な静的型チェッカー（Typechecker）が背後でどのような圏論的・型理論的公理に基づいているかを理解していなければ、大規模なコードベースの型安全性は崩壊する。
今回は、Hack言語における厳格モード（Strict Mode）の核心である共変（Covariance: `+`）と反変（Contravariance: `-`）の完全理解に焦点を当て、HHVMのランタイムおよび型チェッカーの内部メカニズムと結びつけてその正体を暴く。
—
1. 変性（Variance）とは何か：型チェッカーの視点
まず、前提を共有しよう。Hack（およびPHP/TypeScript等）における型は単なる「データのラベル」ではなく、「値の集合（Set of values）」である。
例えば、`Animal` クラスを継承した `Dog` クラスがある場合、`Dog` は `Animal` の部分集合（Subtype）である。これを次のように表現する。
$$\text{Dog} \sqsubseteq \text{Animal}$$
ここで、ジェネリクス型コンテナ `Container
- 共変 (Covariant): 型の継承関係をそのまま維持する（`Dog` $\sqsubseteq$ `Animal` $\implies$ `Container
` $\sqsubseteq$ `Container `） - 反変 (Contravariant): 型の継承関係を逆転させる（`Dog` $\sqsubseteq$ `Animal` $\implies$ `Container
` $\sqsubseteq$ `Container `） - 非変 (Invariant): 一切の代入関係を認めない（デフォルト）
Hackの型チェッカーは、不変な型安全性を維持するため、ジェネリクスインターフェイスやクラスに対して明示的な変性アノテーションを要求する。
—
2. 共変（Covariance）のメカニズム：`+T` と「生産者」の哲学
共変は、型パラメータの継承方向を維持する。Hackでは、インターフェイスやベクターの型パラメータに対して `+` プレフィックスを付与することで共変を宣言できる。
共変が許される条件：只読性（Producer-only）
コンパイラおよび型チェッカーの内部において、なぜ共変な型に対してメソッドの引数（消費者）として `T` を使うことが禁止されているのか？
次のコードを見てほしい。
<<__Strict>>
namespace HackArchitect\Variance;
interface IProducer<<__Covariant +T>> {
public function produce(): T;
}
class Animal {}
class Dog extends Animal {
public function bark(): void {
echo “Woof!\n”;
}
}
class DogProducer implements IProducer
public function produce(): Dog {
return new Dog();
}
}
もし、`IProducer
// 脳内での型安全性の崩壊シミュレーション
function feedAnimals(IProducer
// ここで Animal を渡したいが、中身が DogProducer だったら…？
// $producer->consume(new Cat()); // 破滅への道
}
共変（`+T`）の本質は、その型が「値を生産する（Producer）専用」であることだ。HHVMの仮想マシン（VM）レベルでも、共変インターフェイスを通じた戻り値の型チェックは、ポインタの共変性（共変戻り値型など）として最適化される。読み出し専用のストリームやコレクションは、すべて共変として設計されるべきである。
—
3. 反変（Contravariance）のメカニズム：`-T` と「消費者」の哲学
反変は、型理論において最も直感に反し、それゆえにバグの温床になりやすい概念だ。Hackでは `-` プレフィックスで定義する。
<<__Strict>>
namespace HackArchitect\Variance;
interface IConsumer<<__Contravariant -T>> {
public function consume(T $item): void;
}
class Animal {}
class Dog extends Animal {}
class AnimalConsumer implements IConsumer
public function consume(Animal $animal): void {
// 何らかの動物の処理
}
}
ここで驚くべき代入ルールが成立する。
$$\text{Dog} \sqsubseteq \text{Animal} \implies \text{IConsumer
なぜ `IConsumer
シニアエンジニアのためのメンタルモデル
「犬専用のフードプロセッサ（`IConsumer
したがって、「消費者（Consumer）」としての振る舞いを持つ型パラメータは、必ず反変（`-T`）でなければならない。
<<__Strict>>
namespace HackArchitect\Variance;
class VarianceDemo {
public static function run(IConsumer
// OK: IConsumer
$dogConsumer->consume(new Dog());
}
public static function test(): void {
$animalConsumer = new AnimalConsumer(); // IConsumer
// 代入ルールのマジック：
// IConsumer
self::run($animalConsumer);
}
}
—
4. HHVMの内部アーキテクチャと型チェッカーの制約
静的型チェッカー（`hh_client` / `hh_server`）は、これらの変性ルールを AST（抽象構文木）および型グラフの構築時に厳密に検証する。
共変・反変の位置（Variance Positions）
型チェッカーは、クラスやインターフェイスの定義をスキャンする際、型パラメータ `T` が出現する位置を厳しく監視している。
1. Covariant Position (+T):
- メソッドの戻り値型
- プロパティの型（読み取り専用の場合）
- 他の共変インターフェイスの型パラメータ
2. Contravariant Position (-T):
- メソッドの引数の型
- 他の反変インターフェイスの型パラメータ
3. Invariant Position (指定なし):
- メソッドの引数 かつ 戻り値の両方に現れる場合
- 書き込み可能なプロパティの型
もし、不変（Invariant）であるべき型パラメータに対して `+T` や `-T` を付与すると、HHVMの型チェッカーは直ちに `Invalid variance` エラーを投げる。これは、バイトコード生成（`hhbc`）の段階で最適化の前提（ディスパッチテーブルの安全性）を崩さないための防壁である。
—
5. 実践：関数型プログラミングにおける変性の極意
非同期処理やイベント駆動アーキテクチャにおいて、コールバックやハンドラーを設計する際、変性の理解は必須だ。
以下は、ロガーとイベントハンドラーを組み合わせた、プロダクション品質の高度なサンプルコードである。
<<__Strict>>
namespace HackArchitect\Variance;
// イベントの基底クラス
class Event {}
class HttpCoreEvent extends Event {}
// コールバックは「イベントを受け取る（消費する）」ため、反変 (-T) が最適
interface IEventHandler<<__Contravariant -T>> {
public function handle(T $event): void;
}
// ログ出力器は「メッセージを生産・保持する」ため、共変 (+T) にできるケースもあるが、
// 今回はハンドラーのパイプラインに焦点を当てる。
class EventDispatcher {
// 反変のおかげで、HttpCoreEvent用のリスナーを登録する場所に
// より広範な Event を扱えるリスナーを渡すことができる
public static function dispatch
$handler->handle($event);
}
}
// 使用例
class GenericEventLogger implements IEventHandler
public function handle(Event $event): void {
echo “Logging generic event: ” . static::class . “\n”;
}
}
<<__EntryPoint>>
function main(): void {
$logger = new GenericEventLogger(); // IEventHandler
$httpEvent = new HttpCoreEvent();
// IEventHandler
// より抽象的な IEventHandler
EventDispatcher::dispatch($httpEvent, $logger);
}
この設計により、個別のイベントごとにハンドラーを乱立させる必要がなくなり、汎用的な上位ハンドラーを下位のイベントディスパッチシステムにシームレスに組み込むことが可能になる。これが、変性を理解したエンジニアが構築するスケーラブルなアーキテクチャである。
—
6. まとめ
Hack言語の厳格モードとHHVMのランタイムは、曖昧な型安全性を一切許容しない。
- 生産者（Producer）は共変（`+T`）: データを外へ出すだけなので、より具体的な型（`Dog`）を出すものは、より抽象的な型（`Animal`）の代わりになれる。
- 消費者（Consumer）は反変（`-T`）: データを中で受け取るだけなので、より抽象的な型（`Animal`）を受け取れるものは、より具体的な型（`Dog`）を要求する場所で完全に機能する。
この2つの原則を脳内に焼き付け、型チェッカーの挙動を味方につけたとき、あなたの書くHackコードは、バグの入り込む隙間がない堅牢な要塞と化すだろう。アーキテクトとしての誇りを持ち、常に型の向き（Direction）を意識した設計を心がけてほしい。