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

このデフォルトの挙動、つまり`Vector`が`Vector`のサブタイプではない状態を「不変（Invariant）」と呼ぶ。Hackのジェネリクス型パラメータは、明示的に指定しない限り、全て不変だ。これは最も安全な選択だが、時には柔軟性を欠く。そこで登場するのが`covariant`と`contravariant`だ。

Covariance（共変）を掌握する：読み出し専用の柔軟性

共変性とは、ジェネリクス型パラメータ`T`が、そのコンテナ型`Container`のサブタイプ関係と同じ方向に変化することを意味する。つまり、`Child`が`Parent`のサブタイプであるならば、`Container`も`Container`のサブタイプとなる。

Hackでは、型パラメータの前に`+`記号、または`covariant`キーワードを付加することで共変性を宣言する。

数学的背景と直感的な理解

共変性は、Tを「生成する」または「読み出す」コンテキストで安全に適用できる。
もしあなたが`Animal`を「提供する」インターフェースを持っているとして、それを`Dog`を「提供する」インターフェースで置き換えることは常に安全だろう。なぜなら、`Dog`は`Animal`の一種だからだ。`Animal`を期待する側は、`Dog`を受け取っても何も困らない。

リスコフの置換原則（Liskov Substitution Principle, LSP）の観点から見ると、`f(T)`という関数が`T`型の値を返す場合、`f(Child)`を`f(Parent)`の代わりに用いることができる。

Hackにおける`covariant`の適用

`covariant`キーワードは、ジェネリクス型パラメータが「出力」専用であることを型チェッカーに教える。

/
interface IProducer<+T> { // <+T> または
public function produce(): T;
}

// AnimalFactory: Animalを生成する具体的な実装
class AnimalFactory implements IProducer {
public function produce(): Animal {
return new Animal();
}
}

// DogFactory: Dogを生成する具体的な実装
class DogFactory implements IProducer {
public function produce(): Dog {
return new Dog();
}
}

// この関数はAnimalを生成するファクトリを受け取る
function processAnimalProducer(IProducer $producer): void {
$animal = $producer->produce();
echo “Processing animal: ” . $animal->sound() . “\n”;
}

function run_covariant_example(): void {
$animalFactory = new AnimalFactory();
$dogFactory = new DogFactory();

// IProducer は IProducer のサブタイプとして扱われるため、
// DogFactoryをAnimalFactoryを期待する関数に渡せる。
// これが共変性の力だ！
processAnimalProducer($animalFactory); // Output: Processing animal: Generic animal sound
processAnimalProducer($dogFactory); // Output: Processing animal: Woof!

// 共変性により、より具体的な型を受け取ることも可能
$dogProducer: IProducer = $dogFactory;
$animalProducer: IProducer = $dogFactory; // 型エラーなし！

// しかし、共変型パラメータ T はメソッドの引数には使えない
// class BadProducer<+T> { public function consume(T $item): void {} } // 型エラー: 共変型パラメータ T を引数に使うことはできない
}

run_covariant_example();

HHVMとパフォーマンスへの影響:
`covariant`指定は、コンパイル時における型チェッカーの検証を柔軟にするものであり、HHVMのランタイムパフォーマンスに直接的なオーバーヘッドを課すものではない。むしろ、型チェッカーがより多くのコードパスで型安全を保証できるようになるため、開発者は安心して型に頼った最適化や設計を進めることができる。これにより、ランタイムでの不要な型チェックやエラーハンドリングを減らし、結果的に堅牢で高性能なシステムを構築するための強力な基盤となる。

設計パターンへの応用

• ファクトリパターン: `IProducer<+T>`のように、特定の型を生成するファクトリは共変にすることで、より具体的な型のファクトリを汎用的なファクトリとして扱える。
• イテレータ: `Iterator<+T>`のように、要素を順次提供するインターフェースは共変にすることで、`Iterator`を`Iterator`として扱うことが可能になる。
• 読み出し専用のデータ構造: `Vector<+T>`（Hackのビルトイン`Vector`は不変だが、もし読み出し専用の`ReadOnlyVector`を定義するなら）のように、要素の追加・変更がないコレクション。

Contravariance（反変）を掌握する：書き込み専用の柔軟性

反変性とは、ジェネリクス型パラメータ`T`が、そのコンテナ型`Container`のサブタイプ関係と逆の方向に変化することを意味する。つまり、`Child`が`Parent`のサブタイプであるならば、`Container`が`Container`のサブタイプとなる。

Hackでは、型パラメータの前に`-`記号、または`contravariant`キーワードを付加することで反変性を宣言する。

数学的背景と直感的な理解

反変性は、Tを「消費する」または「書き込む」コンテキストで安全に適用できる。
もしあなたが`Dog`を「受け取る」インターフェースを持っているとして、それを`Animal`を「受け取る」インターフェースで置き換えることは常に安全だろう。なぜなら、`Dog`を受け取れるものは、当然`Animal`も受け取れる（そして`Animal`を`Dog`として扱うことはしない）からだ。`Animal`を受け取れるものは、より具体的な型である`Dog`も問題なく処理できるはずだ。

リスコフの置換原則の観点から見ると、`f(T)`という関数が`T`型の値を引数として受け取る場合、`f(Parent)`を`f(Child)`の代わりに用いることができる。

Hackにおける`contravariant`の適用

`contravariant`キーワードは、ジェネリクス型パラメータが「入力」専用であることを型チェッカーに教える。

/
interface IComparator<-T> { // <-T> または
public function compare(T $a, T $b): int;
}

// AnimalComparator: Animalを比較する具体的な実装
class AnimalComparator implements IComparator {
public function compare(Animal $a, Animal $b): int {
// 実際にはもっと複雑なロジック
return $a->sound() <=> $b->sound();
}
}

// DogComparator: Dogを比較する具体的な実装
class DogComparator implements IComparator {
public function compare(Dog $a, Dog $b): int {
// Dogに特化した比較ロジック
return $a->fetch() <=> $b->fetch();
}
}

// この関数はDogを比較するコンパレータを受け取る
function sortDogs(Vector $dogs, IComparator $comparator): void {
echo “Sorting dogs…\n”;
// 実際にはソートロジック
foreach ($dogs as $dog) {
echo ” ” . $dog->sound() . “\n”;
}
}

function run_contravariant_example(): void {
$animalComparator = new AnimalComparator();
$dogComparator = new DogComparator();

$dogs = Vector {new Dog(), new Dog()};

// IComparator は IComparator のサブタイプとして扱われるため、
// AnimalComparatorをDogを期待する関数に渡せる。
// これが反変性の力だ！
sortDogs($dogs, $dogComparator); // DogComparatorはDogを比較できる
sortDogs($dogs, $animalComparator); // AnimalComparatorはAnimal（Dogの親）を比較できるので、Dogも比較可能

// 反変性により、より汎用的な型を受け取ることも可能
$dogComparer: IComparator = $dogComparator;
$animalComparer: IComparator = $animalComparator;
$dogComparer2: IComparator = $animalComparator; // 型エラーなし！ (AnimalComparator は DogComparator の上位互換)

// しかし、反変型パラメータ T はメソッドの戻り値には使えない
// class BadConsumer<-T> { public function get(): T {} } // 型エラー: 反変型パラメータ T を戻り値に使うことはできない
}

run_contravariant_example();

HHVMとパフォーマンスへの影響:
共変性と同様に、反変性の指定もHHVMのランタイムパフォーマンスに直接的な負のオーバーヘッドをもたらすものではない。むしろ、型チェッカーがコンパイル時に厳密な検証を行うことで、`ClassCastException`のような型の不整合による実行時エラーを未然に防ぎ、アプリケーション全体の安定性と予測可能性を高める。HHVMはこの厳密な型情報を最大限に利用し、より効率的なJITコンパイルとコード生成を行うため、結果として高性能なアプリケーションが実現される。

設計パターンへの応用

• コンパレータ: `IComparator<-T>`のように、2つのオブジェクトを比較するインターフェースは反変にすることで、より汎用的なコンパレータを特定の型のソートに利用できる。
• イベントハンドラ/オブザーバー: `IEventHandler<-TEvent>`のように、特定のイベントを受け取って処理するハンドラは反変にすることで、より汎用的なイベントハンドラを特定のイベントタイプに登録できる。
• 消費者（Consumer）: `IConsumer<-T>`のように、データを受け取って何らかの操作を行うインターフェース。

不変（Invariant）の重要性：デフォルトは常に安全

Hackにおいて、ジェネリクス型パラメータは明示的に`+`や`-`を付けない限り、不変（Invariant）である。これは、`Vector`が`Vector`のサブタイプでもなければ、その逆でもないことを意味する。

{
public function add(T $item): void;
public function get(): T;
}

class AnimalContainer implements IContainer {
private Vector $items = Vector {};
public function add(Animal $item): void { $this->items->add($item); }
public function get(): Animal { return $this->items->at(0); } // 簡略化
}

class DogContainer implements IContainer {
private Vector $items = Vector {};
public function add(Dog $item): void { $this->items->add($item); }
public function get(): Dog { return $this->items->at(0); } // 簡略化
}

function run_invariant_example(): void {
$animalContainer = new AnimalContainer();
$dogContainer = new DogContainer();

// 型エラー: IContainer は IContainer のサブタイプではない
// $x: IContainer = $dogContainer;

// 型エラー: IContainer は IContainer のサブタイプではない
// $y: IContainer = $animalContainer;

// なぜこれが安全なのか？
// もし $x = $dogContainer; が許されたら、
// $x->add(new Cat()); // これは $dogContainer に Cat を追加しようとすることになる
// しかし $dogContainer は Dog しか受け入れない。これが型安全性の破綻だ。

// 同様に、もし $y = $animalContainer; が許されたら、
// $dog = $y->get(); // $dog は Dog と期待されるが、実際には AnimalContainer から Animal が返る可能性がある
// $dog->fetch(); // この時点でエラーになる
}

run_invariant_example();

不変性がデフォルトである理由は、`T`がジェネリクス型の中で入力（引数）としても出力（戻り値）としても使われる場合、型安全性を維持するためには変位を適用できないからだ。`IContainer`のように、`add`メソッドで`T`を消費し、`get`メソッドで`T`を生成する場合、共変性も反変性も適用できない。もし適用してしまうと、先の例で示したような実行時型エラーが発生する。

このデフォルトの不変性こそが、Hackが提供する堅牢な静的型付けの基盤であり、意図しない型混入や実行時エラーからシステムを守る最後の砦だ。

Hackの型チェッカーとHHVMの視点から

私がコミットしてきたHackの型チェッカーは、ここで解説した共変性、反変性、不変性のルールを極めて厳密に適用する。`covariant`や`contravariant`キーワードは、単なるヒントではない。それは、型チェッカーがそのジェネリクス型パラメータが「どこで」「どのように」使われるべきかを示す、強制力のある契約なのだ。

• コンパイル時の保証: 型チェッカーは、共変型パラメータが入力位置（メソッドの引数）に使われていないか、反変型パラメータが出力位置（メソッドの戻り値）に使われていないかを厳密に検証する。これにより、コードがHHVM上で実行される前に、リスコフの置換原則に反するような型不整合の可能性を完全に排除する。
• HHVMの恩恵: HHVMは、この型チェッカーによって保証された型情報を最大限に活用する。JITコンパイルの過程で、型情報が明確であるほど、より積極的な最適化が可能になる。例えば、ある変数の型が`Dog`であることが静的に保証されていれば、`instanceof Dog`のようなランタイムチェックを省略したり、`Dog`クラスのメソッド呼び出しを直接インライン化したりする余地が生まれる。変位指定は、この型保証の範囲を拡大し、結果としてより高速で安定したコードの生成に寄与する。ランタイムで型の不整合による致命的なエラーに遭遇する確率は限りなくゼロに収束する。

これは、PHPのような動的型付け言語では決して得られない、コンパイル時に与えられる究極の安心感だ。

実務での応用と注意点：堅牢なAPI設計のために

共変性、反変性は、あなたのAPIやコンポーネントをより柔軟で、かつ型安全にするための強力なツールだ。

いつ、どのように変位を適用すべきか？

• APIの柔軟性を高める: 外部に公開するインターフェースや、ライブラリの設計において、クライアントコードの使い勝手を向上させる。例えば、`IProducer<+T>`として公開すれば、`IProducer`を期待する場所で`IProducer`が受け入れられるようになるため、より汎用的なコードが書けるようになる。
• データフローの方向性:
• データを「生成」または「読み出す」インターフェース: `IProducer<+T>`, `IIterator<+T>`, `IObservable<+T>` のように、型`T`をメソッドの戻り値として返す、あるいはフィールドとして持つ場合は`covariant`を検討する。
• データを「消費」または「書き込む」インターフェース: `IConsumer<-T>`, `IComparator<-T>`, `IObserver<-T>` のように、型`T`をメソッドの引数として受け取る場合は`contravariant`を検討する。
• 不変性がデフォルトである理由を常に意識する: もしジェネリクス型パラメータが、入力と出力の両方に使われる可能性があるなら、それは不変であるべきだ。例えば、ミュータブルなコレクション（`MutableVector`のようなもの）は、要素の追加（消費）と取得（生成）の両方を行うため、不変でなければ型安全を保てない。

間違った変位指定が引き起こす問題

Hackの型チェッカーは、間違った変位指定を許さない。例えば、共変型パラメータをメソッドの引数に使おうとすると、即座に型エラーとなる。

{
// 型エラー: Coerced type parameter T is used in a contravariant position.
public function consume(T $item): void;
}

この厳しさが、君たちのコードをあらゆる実行時エラーから守る。型チェッカーは、開発者の意図とコードの実際の振る舞いの間に矛盾がないかを徹底的に検証する。この段階でエラーを潰すことが、デバッグコストを劇的に削減し、プロダクションコードの信頼性を高める唯一の道だ。

設計のベストプラクティス

• インターフェースを小さく保つ: 変位を適用したいなら、インターフェースを「生成専用」「消費専用」など、単一の責任に限定することで、自然に変位を指定しやすくなる。
• 読み出し専用と書き込み専用を分ける: 例えば、`IReadOnlyList<+T>`と`IMutableList`のように、APIを分割することで、読み出し専用のインターフェースには共変性を適用し、ミュータブルなインターフェースは不変性を保つことができる。
• APIドキュメントに変位を明記する: 利用者にとって、そのジェネリクス型パラメータが共変なのか、反変なのか、不変なのかは非常に重要な情報だ。明確なドキュメントは、誤用を防ぐ。

まとめ

Hackにおける共変性、反変性、そして不変性は、単なる学術的な概念ではない。これらは、型チェッカーが提供する強力な型安全性の保証を最大限に活用し、あなたのシステムをより堅牢に、より柔軟に、そして究極的にはより保守しやすくするための、実践的な設計原則だ。

型変位を理解し、適切に適用することで、あなたは以下を達成できる：

1. 実行時エラーの劇的な削減: 型チェッカーがコンパイル時に潜在的な型不整合を排除する。
2. APIの柔軟性と再利用性の向上: より抽象的なコードで、より具体的な型のデータを扱えるようになる。
3. コードの意図の明確化: ジェネリクス型パラメータの使われ方が明確になり、コードの可読性が向上する。

Hackの静的型システムは、その厳格さの中に深い洞察と強力な能力を秘めている。この変位の概念を真に掌握した時、あなたのコードは一段と洗練され、いかなる複雑な問題にも立ち向かえる、本物の「プロダクションレディ」な設計へと昇華するだろう。さあ、この知識を武器に、次のプロジェクトへと挑むのだ。