型のばらつき

コンピュータプログラミングにおいて、型バリアンスとは、複合型（例List[Int]：）のサブタイプと、その構成要素のサブタイプ（例：）との間の関係を指します。言語で選択されたバリアンスによって、例えば、のリストとのリスト、あるいはを返す関数とを返す関数Intとの間の関係が決まります。CatAnimalCatAnimal

型Catがのサブタイプである場合Animal、型の式は、型の式が使用される場所であればどこでも置換可能である必要があります。型コンストラクタの変性に応じて、単純型のサブタイプ関係は、それぞれの複合型に対して保持、反転、または無視される場合があります。たとえば、多くのプログラミング言語では、リスト型コンストラクタが共変であるため、「Cat のリスト」は「Animal のリスト」のサブタイプになります。これは、単純型のサブタイプ関係が複合型に対して保持されることを意味します。一方、「Animal から String への関数」は、関数型コンストラクタがパラメータ型に対して反変であるため、「Cat から String への関数」のサブタイプになります。ここでは、単純型のサブタイプ関係が複合型に対して反転されます。CatAnimal

プログラミング言語の設計者は、配列、継承、汎用データ型などの言語機能の型規則を考案する際に、型の不変性を考慮します。型コンストラクタを不変ではなく共変または反変にすることで、より多くのプログラムが型が正しく記述されていると認識されるようになります。一方で、プログラマーは反変性を直感的ではないと感じることが多く、実行時型エラーを回避するために型の不変性を正確に追跡すると、複雑な型規則につながる可能性があります。

型システムをシンプルに保ち、有用なプログラムを可能にするために、言語は、型コンストラクタを可変とみなしても安全であっても不変として扱うこともあれば、型安全性に違反する可能性があるにもかかわらず共変として扱うこともあります。

語源

これらの用語は、圏論における共変関手と反変関手の概念に由来する。圏を考えてみよう。 $C$ オブジェクトが型であり、射が部分型関係 ≤ を表す。（これは、任意の半順序集合をカテゴリとみなす方法の一例です。）例えば、関数型コンストラクタは 2 つの型pとrを受け取り、新しい型p → rを作成します。つまり、オブジェクトを受け取ります。 $C^{2}$ オブジェクトへ $C$ 関数型のサブタイピング規則により、この操作は最初のパラメータの ≤ を反転させ、2 番目のパラメータの ≤ を保持するため、最初のパラメータでは反変関数であり、2 番目のパラメータでは共変関数となります。

正式な定義

とAをB型とし、は型引数を持つ型コンストラクタI<U>の適用を表すとする。プログラミング言語の型システムにおいて、型コンストラクタの型付け規則は次のようになる。IUI

共変とは、型の順序（≤）を保持することであり、型をより具体的なものからより一般的なものへと順序付けることを意味します。A ≤ Bの場合、 ;I<A> ≤ I<B>
この順序を反転させる場合は反変であるA ≤ B:の場合、 ;I<B> ≤ I<A>
両方が当てはまる場合は二変量A ≤ B（つまり、の場合、）；^[^注1^]I<A> ≡ I<B>
共変、反変、または二変の場合の変異。
不変でない場合は、不変または非不変である。

この記事では、これが一般的な型コンストラクタにどのように適用されるかを考察する。

C# の例

例えば、C#では、 Catがのサブタイプである場合Animal、次のようになります。

IEnumerable<Cat>はのサブタイプです。はに対して共変であるため、サブタイプ化は保持されます。IEnumerable<Animal>IEnumerable<T>T
Action<Animal>はのサブタイプです。はに対して反変であるため、サブタイプ化は逆になります。Action<Cat>Action<T>T
もも、もう一方のサブタイプではありません。なぜならは上で不変だからです。IList<Cat>IList<Animal>IList<T>T

C# のジェネリックインターフェイスのバリアンスは、その型パラメーター (0 個以上) に (out共変) または(反変) 属性を配置することによって宣言されます。 ^[¹^]^:¹⁴⁴上記のインターフェイスは、、、およびとして宣言されます。複数の型パラメーターを持つ型は、各型パラメーターに異なるバリアンスを指定できます。たとえば、デリゲート型は、型の反変入力パラメーターと型の共変戻り値を持つ関数を表します。^[²^]^[¹^]^:¹⁴⁵コンパイラは、すべての型が注釈と一貫して定義および使用されているかどうかをチェックし、そうでない場合はコンパイルエラーを通知します。inIEnumerable<outT>Action<inT>IList<T>Func<inT,outTResult>TTResult

インターフェースのバリアンスの型規則は、型の安全性を保証します。たとえば、は、型の引数を期待する第一級関数を表します。[ ¹^]^:¹⁴⁴^また、あらゆる種類の動物を処理できる関数は、猫しか処理できない関数の代わりに常に使用できます。Action<T>T

配列

読み取り専用データ型（ソース）は共変である可能性があり、書き込み専用データ型（シンク）は反変である可能性があります。ソースとシンクの両方として機能する可変データ型は不変であるべきです。この一般的な現象を説明するために、配列型を考えてみましょう。型に対して、型を「動物の配列」にすることができます。この例では、この配列は要素の読み取りと書き込みの両方をサポートしています。AnimalAnimal[]

私たちはこれを以下のいずれかの方法で扱うことができます。

共変: aは;Cat[]Animal[]
反変: an はa です。Animal[]Cat[]
不変条件: an はa ではなく、aは an ではありません。Animal[]Cat[]Cat[]Animal[]

型エラーを回避したい場合、3番目の選択肢のみが安全です。明らかに、すべてのをとして扱うことはできません。配列から読み込むクライアントはを期待しますが、にはたとえばが含まれる可能性があるからです。したがって、反変ルールは安全ではありません。Animal[]Cat[]CatAnimal[]Dog

逆に、をとして扱うことはできません。をに格納することは常に可能であるべきです。共変配列の場合、バッキングストアが実際には猫の配列である可能性があるため、これが安全であるとは保証できません。したがって、共変ルールも安全ではありません。配列コンストラクタは不変である必要があります。これは可変配列の場合のみ問題となることに注意してください。共変ルールは不変（読み取り専用）配列では安全です。同様に、反変ルールは書き込み専用配列では安全です。Cat[]Animal[]DogAnimal[]

JavaとC#における共変配列

JavaやC#の初期バージョンには、ジェネリクス（パラメトリック多相性とも呼ばれる）は含まれていませんでした。このような環境では、配列を不変にしてしまうと、有用な多相性プログラムを作成できなくなります。

例えば、配列をシャッフルする関数や、要素に対して . メソッドを使用して 2 つの配列の等価性をテストする関数を作成することを考えてみましょう。Object実装は配列に格納されている要素の正確な型に依存しないため、すべての型の配列で動作する単一の関数を作成することが可能です。次のような型の関数は簡単に実装できます。equals

boolean equalArrays ( Object [] a1 , Object [] a2 ); void shuffleArray ( Object [] a );

しかし、配列の型が不変であるとみなされた場合、これらの関数は、まさに型の配列に対してのみ呼び出すことができる。例えば、文字列の配列をシャッフルすることはできない。Object[]

したがって、JavaとC#はどちらも配列型を共変的に扱います。たとえば、Javaでははのサブタイプであり、C#でははのサブタイプです。String[]Object[]string[]object[]

前述のように、共変配列は配列への書き込みで問題を引き起こします。Java ^{[ 3 ]}^{: 126}と C# は、配列オブジェクトの作成時に各オブジェクトに型をマークすることでこの問題に対処します。値が配列に格納されるたびに、実行環境は値の実行時型が配列の実行時型と等しいかどうかを確認します。不一致がある場合は、(Java) ^[³^]^:¹²⁶または(C#) がスローされます。ArrayStoreExceptionArrayTypeMismatchException

// a は String の単一要素配列ですString [] a = new String [ 1 ] ;// b は Object の配列ですObject [] b = a ;// b に整数 (int) を代入します。これは、b が実際にObject の配列であれば可能ですが、実際には String の配列であるため、実行時に java.lang.ArrayStoreException が発生します。b [ 0 ] = 1 ;

上記の例では、配列(b)からの読み取りは安全に行えます。問題となるのは、配列への書き込みを試みる場合のみです。

このアプローチの欠点の1つは、より厳密な型システムであればコンパイル時に検出できたはずの実行時エラーが発生する可能性があることです。また、配列への書き込みごとに実行時チェックが追加で必要となるため、パフォーマンスが低下します。

ジェネリクスの追加により、Java ^{[ 3 ]}^{: 126–129}と C# では、共変性に頼らずにこの種の多相関数を記述する方法が提供されるようになりました。配列比較関数とシャッフル関数には、パラメータ化された型を指定できます。

<T> boolean equalArrays ( T [ ] a1 , T [] a2 ) ; <T> void shuffleArray ( T [ ] a ) ;

あるいは、C# メソッドがコレクションに読み取り専用でアクセスするように強制するには、配列を渡す代わりにインターフェースを使用できます。IEnumerable<object>object[]

関数型

第一級関数を持つ言語には、「Cat を引数として受け取り、Animal を返す関数」（OCaml構文またはC#構文で記述）のような関数型があります。cat->animalFunc<Cat,Animal>

これらの言語では、ある関数型が別の関数型のサブタイプである場合、つまり、異なる型の関数を期待するコンテキストで、ある型の関数を安全に使用できる場合も指定する必要があります。関数f が g よりも一般的な型の引数を受け取り、g よりも具体的な型を返す場合、関数 f を関数gの代わりに使用しても安全です。たとえば、型、、の関数は、が期待される場所であればどこでも使用できます。（これは、通信の堅牢性の原則「受け入れるものには寛容に、生成するものには保守的に」と比較できます。）一般的なルールは次のとおりです。animal->catcat->catanimal->animalcat->animal

(P_{1}\rightarrow R_{1})\leq (P_{2}\rightarrow R_{2})

もし

P_{1}\geq P_{2}

そして

R_{1}\leq R_{2}

。

推論規則表記を用いると、同じ規則は次のように記述できます。

{\frac {P_{1}\geq P_{2}\quad R_{1}\leq R_{2}}{(P_{1}\rightarrow R_{1})\leq (P_{2}\rightarrow R_{2})}}

言い換えれば、→型コンストラクタは、パラメータ（入力）型に対して反変であり、戻り値（出力）型に対して共変である。この規則は、最初にジョン・C・レイノルズによって正式に述べられ^{[ 4 ]}、ルカ・カルデッリの論文でさらに普及した^[⁵^]。

関数を引数として取る関数を扱う場合、このルールは複数回適用できます。たとえば、このルールを2回適用すると、次のことがわかります。 $((P_{1}\to R)\to R)\leq ((P_{2}\to R)\to R)$ もし $P_{1}\leq P_{2}$ つまり、そのタイプは $((A\to B)\to C)$ の位置において共変である $A$ 複雑な型の場合、特定の型特殊化が型安全であるか否かを頭の中でたどるのは混乱を招く可能性がありますが、どの位置が共変でどの位置が反変であるかを計算するのは簡単です。位置は、偶数個の矢印が適用される左側にある場合に共変です。

オブジェクト指向言語における継承

オブジェクト指向プログラミング（OOP）言語では、サブクラスがスーパークラスのメソッドをオーバーライドする場合、コンパイラはオーバーライドするメソッドが正しい型を持っているかどうかをチェックする必要があります。一部の言語では、型がスーパークラスの型と完全に一致する必要がある（不変性）一方で、オーバーライドするメソッドが「より適切な」型を持つことも型安全です。関数型の通常のサブタイピング規則によれば、これはオーバーライドするメソッドがより具体的な型を返し（戻り値の型共変性）、より一般的な引数を受け入れる（引数型の反変性）必要があることを意味します。統一モデリング言語（UML）表記では、可能性は次のようになります（クラスBはスーパークラスであるクラスAを継承するサブクラスです）。

バリアンスとメソッドのオーバーライド：概要
メソッドのパラメータ/戻り値の型のサブタイピング。
不変性。オーバーライドするメソッドのシグネチャは変更されません。
共変戻り値型。サブタイピング関係は、ClassAとClassBの関係と同じ方向です。
反変パラメータ型。サブタイピング関係は、ClassAとClassBの関係とは逆方向です。
共変パラメータ型。型安全ではありません。

具体的な例として、動物シェルターをモデル化するクラスを作成するとします。はのサブクラスであり、は ( Java 構文を使用して)基底クラスであると仮定します。CatAnimal

クラスAnimalShelter {Animal getAnimalForAdoption ( ) { // ... } void putAnimal ( Animal ) { //... } }

さて、問題は、をサブクラス化する場合、とにどのような型を与えることができるかということです。AnimalSheltergetAnimalForAdoptionputAnimal

共変メソッドの戻り値の型

共変戻り値型を許容する言語では、派生クラスはメソッドをオーバーライドして、より具体的な型を返すことができます。getAnimalForAdoption

class CatShelter extends AnimalShelter {Cat getAnimalForAdoption () { return new Cat (); } }

主流のオブジェクト指向プログラミング言語の中で、Java、C++、C#（バージョン9.0以降^{[ 6 ]}）は共変戻り値型をサポートしています。共変戻り値型の追加は、1998年に標準化委員会によって承認されたC++言語の最初の変更の1つでした^{[ 7 ]}。ScalaとD も共変戻り値型をサポートしています。

反変法パラメータタイプ

同様に、オーバーライドするメソッドが基底クラスのメソッドよりも一般的な引数を受け入れることを許可しても、型安全性は保たれます。

class CatShelter extends AnimalShelter { void putAnimal ( Object animal ) { // ... } }

実際にこれを許可するオブジェクト指向言語はごく少数です（例えば、mypyで型チェックを行うPythonなど）。C++、Java、およびオーバーロードやシャドウイングをサポートするその他のほとんどの言語では、これはオーバーロードまたはシャドウイングされた名前を持つメソッドとして解釈されます。

しかし、Sather は共変性と反変性の両方をサポートしていました。オーバーライドされたメソッドの呼び出し規約は、出力パラメータと戻り値に関しては共変性であり、通常のパラメータ（モードがの場合）に関しては反変性です。

共変法パラメータタイプ

EiffelやDart ^{[ 8 ]}といった主流のプログラミング言語では、オーバーライドするメソッドのパラメータが、スーパークラスのメソッドよりも具体的な型を持つことが許されています（パラメータ型の共変性）。したがって、基底クラスのメソッドをオーバーライドする以下のDartコードは、型チェックに合格します。putAnimal

class CatShelter extends AnimalShelter {void putAnimal ( covariant Cat animal ) { // ... } }

これは型安全ではありません。をにアップキャストすることで、犬を猫シェルターに入れようとすることができます。これはパラメータの制約を満たさず、実行時エラーになります。型安全性の欠如（Eiffel コミュニティでは「catcall 問題」として知られており、「cat」または「CAT」は変更された可用性または型です）は長年の問題でした。長年にわたり、グローバル静的解析、ローカル静的解析、および新しい言語機能のさまざまな組み合わせがこれを解決するために提案され、^[⁹^]^[¹⁰^]これらは一部の Eiffel コンパイラで実装されています。CatShelterAnimalShelterCatShelter

型安全性の問題にもかかわらず、Eiffel の設計者は、現実世界の要件をモデル化するために共変パラメータ型が重要だと考えている。^{[ 10 ]}猫シェルターは一般的な現象を示している。それは一種の動物シェルターだが、追加の制約があり、これをモデル化するために継承と制限付きパラメータ型を使用するのは妥当と思われる。この継承の使用を提案するにあたり、Eiffel の設計者は、サブクラスのオブジェクトは常にスーパークラスのオブジェクトよりも制約が少ないべきであるというLiskov 置換原則を拒否している。

メソッドパラメータの共変性を許容する主流言語のもう1つの例は、PHPのクラスコンストラクタに関するものです。次の例では、__construct() メソッドは、メソッドパラメータが親クラスのメソッドパラメータと共変であるにもかかわらず、受け入れられます。このメソッドが __construct() 以外のものであれば、エラーが発生します。

インターフェースAnimalInterface {}interface DogInterface extends AnimalInterface {}class Dog implements DogInterface {}class Pet { public function __construct ( AnimalInterface $animal ) {} }class PetDog extends Pet { public function __construct ( DogInterface $dog ) { parent :: __construct ( $dog ); } }

共変パラメータが役立つもう1つの例は、いわゆるバイナリメソッドです。バイナリメソッドとは、パラメータがメソッド呼び出し対象のオブジェクトと同じ型であることが期待されるメソッドのことです。例えば、`a` メソッドは、`b` が何らかの順序で `a`より前か後かをチェックしますが、例えば2つの有理数を比較する方法は、2つの文字列を比較する方法とは異なります。バイナリメソッドのその他の一般的な例としては、等価性テスト、算術演算、部分集合や和集合などの集合演算が挙げられます。compareToa.compareTo(b)ab

Javaの旧バージョンでは、比較メソッドはインターフェースとして指定されていました。Comparable

インターフェースComparable {int compareTo ( Object o ); }

この方法の欠点は、メソッドが型の引数を取るように指定されていることです。一般的な実装では、まずこの引数をダウンキャストします（期待される型でない場合はエラーをスローします）。Object

class RationalNumber implements Comparable { int numerator ; int denominator ; // ... public int compareTo ( Object other ) { RationalNumber otherNum = ( RationalNumber ) other ; return Integer . compare ( numerator * otherNum . denominator , otherNum . numerator * denominator ); } }

共変パラメータを持つ言語では、引数に目的の型を直接指定することで、型キャストを隠蔽できます。（もちろん、例えばに対してが呼び出された場合、実行時エラーが発生します。）compareToRationalNumbercompareToString

共変パラメータ型の必要性を回避する

その他の言語機能を用いることで、リスコフの置換可能性を維持しながら、共変パラメータの明らかな利点を提供することができる。

ジェネリクス（別名パラメトリック多相性）と境界量化を備えた言語では、前述の例を型安全な方法で記述できます。^{[ 11 ]}を定義する代わりに、パラメータ化されたクラスを定義します。（この方法の欠点の1つは、基底クラスの実装者が、サブクラスでどの型を特殊化する必要があるかを予測する必要があることです。）AnimalShelterShelter<T>

class Shelter < T extends Animal > {T getAnimalForAdoption () { // ... }void putAnimal ( T動物) { // ... } }class CatShelter extends Shelter < Cat > {Cat getAnimalForAdoption () { // ... }void putAnimal (猫の動物) { // ... } }

同様に、Javaの最近のバージョンではインターフェースがパラメータ化されており、型安全な方法でダウンキャストを省略できるようになっています。Comparable

class RationalNumber implements Comparable < RationalNumber > {int numerator ; int denominator ; // ... public int compareTo ( RationalNumber otherNum ) { return Integer.compare ( numerator * otherNum.denominator , otherNum.numerator * denominator ) ; } }

もう一つ役立つ言語機能は、多重ディスパッチです。バイナリメソッドの記述が難しい理由の一つは、のような呼び出しでは、の正しい実装を選択するにはとの両方の実行時型に依存するのに対し、従来のオブジェクト指向言語ではの実行時型のみを考慮する必要があるからです。共通リスプオブジェクトシステム（CLOS）スタイルの多重ディスパッチを備えた言語では、比較メソッドを、両方の引数をメソッド選択に使用する汎用関数として記述できます。a.compareTo(b)compareToaba

ジュゼッペ・カスタニャ^{[ 12 ]は}、多重ディスパッチを持つ型付き言語では、汎用関数がディスパッチを制御するパラメータと、制御しない「余剰」パラメータを持つことができると指摘した。メソッド選択ルールは適用可能な最も具体的なメソッドを選択するため、メソッドが別のメソッドをオーバーライドする場合、オーバーライドするメソッドは制御パラメータに対してより具体的な型を持つことになる。一方、型安全性を確保するためには、言語は余剰パラメータが少なくとも同じくらい一般的であることを要求する必要がある。前述の用語を用いると、実行時メソッド選択に使用される型は共変であり、メソッドの実行時メソッド選択に使用されない型は反変である。Javaのような従来の単一ディスパッチ言語もこのルールに従う。メソッド選択には1つの引数（隠し引数としてメソッドに渡されるレシーバオブジェクト）のみを使用し、実際、オーバーライドするメソッド内の型はスーパークラス内よりも特殊化されている。thisthis

カスターニャは、共変パラメータ型が優れている例（特にバイナリメソッド）は、共変性を持つ多重ディスパッチを用いて処理すべきだと提唱している。しかし、ほとんどのプログラミング言語は多重ディスパッチをサポートしていない。

分散と遺伝の概要

以下の表は、上記で説明した言語におけるメソッドのオーバーライドに関する規則をまとめたものです。

一般的なタイプ

ジェネリクス（別名パラメトリック多相性）をサポートするプログラミング言語では、プログラマは新しいコンストラクタで型システムを拡張できます。たとえば、C# のインターフェースでは、やのような新しい型を構築できます。ここで問題となるのは、これらの型コンストラクタのバリアンスをどのように設定すべきかということです。IList<T>IList<Animal>IList<Cat>

主なアプローチは2つあります。宣言箇所でのバリアンス注釈を持つ言語（C#など）では、プログラマーはジェネリック型の定義に、その型パラメータの意図するバリアンスを注釈として付加します。使用箇所でのバリアンス注釈を持つ言語（Javaなど）では、プログラマーはジェネリック型がインスタンス化される箇所に注釈を付加します。

宣言部位の差異注釈

宣言箇所での共変性アノテーションが最も一般的な言語は、C#とKotlin (キーワードoutとを使用in)、およびScalaとOCaml (キーワード+とを使用-) です。C# では共変性アノテーションはインターフェース型にのみ使用できますが、Kotlin、Scala、OCaml ではインターフェース型と具象データ型の両方に使用できます。

インターフェース

C# では、汎用インターフェースの各型パラメーターに、共変 ( out)、反変 ( in)、または不変 (注釈なし) のマークを付けることができます。たとえば、読み取り専用イテレーターのインターフェースを定義し、その型パラメーターに共変 (出力) を宣言することができます。IEnumerator<T>

interface IEnumerator < out T > { T Current { get ; } bool MoveNext (); }

この宣言により、IEnumeratorは型パラメータに関して共変として扱われます。たとえば、はのサブタイプです。IEnumerator<Cat>IEnumerator<Animal>

型チェッカーは、インターフェース内の各メソッド宣言がin/outアノテーションと整合性のある方法で型パラメータのみを記述することを強制します。つまり、共変として宣言されたパラメータは、反変位置（反変な型コンストラクタの奇数個の下で出現する場合、その位置は反変である）に出現してはなりません。正確なルール^{[ 13 ]}^{[ 14 ]}は、インターフェース内のすべてのメソッドの戻り値の型が共変的に有効であり、すべてのメソッドパラメータの型が反変的に有効である必要があるということです。ここで、有効な S-lyは次のように定義されます。

非ジェネリック型（クラス、構造体、列挙型など）は、共変的にも反変的にも有効です。
型パラメータはT、がマークされていない場合は共変的に有効でありin、がマークされていない場合は反変的に有効ですout。
配列型は、以下の条件を満たす場合に有効なS-ly型です。（これは、C#が共変配列を持つためです。）A[]A
ジェネリック型は、各パラメータに対して、 G<A1,A2,...,An>Ai
- Ai は有効な S-ly であり、i番目のパラメータはG共変であると宣言されています。
- Ai は有効 (S ではない)-ly であり、i番目のパラメータはG反変であると宣言されているか、
- Ai は共変的にも反変的にも有効であり、のi番目のパラメータはG不変であると宣言されます。

これらのルールがどのように適用されるかの例として、インターフェースを考えてみましょう。IList<T>

interface IList < T > { void Insert ( int index , T item ); IEnumerator < T > GetEnumerator (); }

Tのパラメータ型はInsert反変的に有効でなければなりません。つまり、型パラメータにTタグを付けてはなりませんout。同様に、の結果型は共変的に有効でなければなりません。つまり、（は共変インターフェースであるため）型は共変的に有効でなければなりません。つまり、型パラメータにタグを付けてはなりません。これは、インターフェースに共変または反変のマークを付けることが許可されていないことを示しています。IEnumerator<T>GetEnumeratorIEnumeratorTTinIList

のような一般的なデータ構造の場合IList、これらの制約により、outパラメータは構造からデータを取り出すメソッドにのみ使用でき、inパラメータは構造にデータを入れるメソッドにのみ使用できるため、キーワードが選択されます。

データ

C# では、インターフェースのパラメーターには共変注釈を付けることができますが、クラスのパラメーターには付けることができません。C# クラスのフィールドは常に可変であるため、C# で可変パラメーターを持つクラスはあまり役に立ちません。しかし、不変データを重視する言語では、共変データ型をうまく活用できます。たとえば、Scala、Kotlin、OCamlのすべてにおいて、不変リスト型は共変です。はのサブタイプです。List[Cat]List[Animal]

Scala のバリアンス注釈のチェック規則は、基本的に C# と同じです。ただし、特に不変データ構造に適用される慣用表現がいくつかあります。それらは、次のクラスの定義 (抜粋) で示されています。List[A]

sealed abstract class List [ + A ] extends AbstractSeq [ A ] { def head : A def tail : List [ A ]/** このリストの先頭に要素を追加します。 */ def :: [ B >: A ] ( x : B ): List [ B ] = new scala . collection . immutable . :: ( x , this ) /** ... */ }

まず、バリアント型を持つクラスメンバーは不変でなければなりません。ここでは、head型はでありA、これは共変型 ( ) として宣言され+、実際にheadメソッド ( def) として宣言されています。これを可変フィールド ( var) として宣言しようとすると、型エラーとして拒否されます。

第二に、データ構造が不変であっても、パラメータの型が反変的に現れるメソッドが存在することがよくあります。たとえば、リストの先頭に要素を追加するメソッドを考えてみましょう。（この実装では、空でないリストのクラスである、同じ名前のクラス::の新しいオブジェクトを作成します。）このメソッドに渡す最も明白な型は、::

def :: ( x : A ):リスト[ A ]

しかし、これは型エラーになります。なぜなら、共変パラメータがA反変位置（関数パラメータとして）に現れるからです。しかし、この問題を回避するトリックがあります。より一般的な型を与え、がのスーパータイプである限り、::任意の型の要素を追加できるようにします。これはが共変であることに依存していることに注意してください。は型を持ち、型を持つものとして扱います。一見すると、一般化された型が健全であることは明らかではないかもしれませんが、プログラマがより単純な型宣言から始めると、型エラーによってを一般化する必要がある場所が示されます。BBAListthisList[A]List[B]

分散の推論

コンパイラがすべてのデータ型パラメータに対して可能な限り最良のバリアンス注釈を自動的に推論するような型システムを設計することは可能です。^{[ 15 ]}しかし、いくつかの理由から分析は複雑になる可能性があります。まず、インターフェースのバリアンスは、そのインターフェースが言及するすべてのインターフェースのバリアンスに依存するため、分析は非局所的です。次に、一意の最良のソリューションを得るためには、型システムは二変パラメータ（共変かつ反変である）を許可する必要があります。最後に、型パラメータのバリアンスは、偶然に起こるものではなく、インターフェースの設計者による意図的な選択であるべきです。II

これらの理由から^{[ 16 ]、}ほとんどの言語はバリアンス推論をほとんど行いません。C#とScalaはバリアンス注釈を全く推論しません。OCamlはパラメータ化された具体的なデータ型のバリアンスを推論できますが、プログラマは抽象型（インターフェース）のバリアンスを明示的に指定する必要があります。

例えば、T関数をラップするOCamlデータ型を考えてみましょう。

type ( ' a , ' b ) t = T of ( ' a -> ' b )

コンパイラはT、最初のパラメータに対して反変であり、2番目のパラメータに対して共変であることを自動的に推論します。プログラマは明示的な注釈を与えることもでき、コンパイラはそれが満たされているかどうかを確認します。したがって、次の宣言は前の宣言と同等です。

型(- ' a , + ' b ) t = T of ( ' a -> ' b )

OCamlでは、インターフェースを指定する際に明示的な注釈が役立ちます。例えば、連想テーブルの標準ライブラリインターフェースには、マップ型コンストラクタが結果型に対して共変であることを示す注釈が含まれています。Map.S

module type S = sig type key type (+ ' a ) t val empty : ' a t val mem : key -> ' a t -> bool ... end

これにより、egがのサブタイプであることが保証されます。catIntMap.tanimalIntMap.t

使用場所の差異を示す注釈（ワイルドカード）

宣言サイト方式の欠点の1つは、多くのインターフェース型を不変にする必要があることです。たとえば、上で見たように、はとのIList両方を含んでいるため、不変にする必要があります。より多くのバリエーションを公開するために、API設計者は、利用可能なメソッドのサブセットを提供する追加のインターフェース（たとえば、のみを提供する「挿入専用リスト」）を提供できます。しかし、これはすぐに扱いにくくなります。InsertGetEnumeratorInsert

使用箇所におけるバリアンスとは、型が使用されるコード内の特定の箇所に注釈を付けることで、必要なバリアンスを指定することを意味します。これにより、クラスの設計者が異なるバリアンスを持つ複数のインターフェースを定義する必要なく、クラスの利用者はサブタイピングを行う機会が増えます。代わりに、ジェネリック型が実際のパラメータ化された型にインスタンス化される時点で、プログラマはメソッドのサブセットのみを使用することを指定できます。事実上、ジェネリッククラスの各定義によって、そのクラスの共変部分と反変部分のインターフェースも利用可能になります。

Java は、制限付き存在型の形式であるワイルドカードを通して、使用箇所のバリアンス注釈を提供します。パラメータ化された型は、ワイルドカードと上限または下限を組み合わせてインスタンス化できます。たとえば、またはです。のような無制限のワイルドカードは、と同等です。このような型は、境界を満たす未知の型を表します。 ^[³^]^:¹³⁹たとえば、が型である場合、型チェッカーはを受け入れます。?List<?extendsAnimal>List<?superAnimal>List<?>List<?extendsObject>List<X>XlList<?extendsAnimal>

動物a = l.get ( 3 ) ;

なぜなら、その型はのサブタイプであることがわかっているが、XAnimal

l.add ( new Animal ( ) );

は必ずしもではないため、型エラーとして拒否されます。一般に、あるインターフェースが与えられた場合、への参照は、メソッドの型にが反変的に出現するインターフェースのメソッドの使用を禁止します。逆に、の型がであれば、を呼び出すことはできますが、を呼び出すことはできません。AnimalXI<T>I<?extendsT>TlList<?superAnimal>l.addl.get

Java の非ワイルドカード型パラメータ化型は不変ですが (たとえば、との間にサブタイピング関係はありません)、ワイルドカード型はより厳密な境界を指定することでより具体的にすることができます。たとえば、はのサブタイプです。これは、ワイルドカード型が上限に関して共変であり(下限に関しても反変である) ことを示しています。つまり、のようなワイルドカード型が与えられた場合、サブタイプを形成する方法は 3 つあります。クラスを特殊化する、より厳密な境界を指定する、またはワイルドカードを特定の型に置き換える(図を参照)。 ^[³^]^:¹³⁹List<Cat>List<Animal>List<?extendsCat>List<?extendsAnimal>C<?extendsT>CT?

上記３つのサブタイピング形式のうち２つを適用することで、例えば、型を期待するメソッドに型の引数を渡すことが可能になります。これは、共変インターフェース型によってもたらされる表現力の一例です。型は、の共変メソッドのみを含むインターフェース型として機能しますが、の実装者はそれを事前に定義する必要はありませんでした。List<Cat>List<?extendsAnimal>List<?extendsAnimal>List<T>List<T>

一般的なデータ構造の場合IList、構造からデータを取り出すメソッドには共変パラメータが、構造にデータを書き込むメソッドには反変パラメータが使用されます。Joshua Bloch著『 Effective Java 』にある「Producer Extends, Consumer Super (PECS)」という覚え方は、共変性と反変性をいつ使うべきかを覚える簡単な方法です。^[³^]^:¹⁴¹

ワイルドカードは柔軟性がありますが、欠点もあります。使用部位の多様性により、API 設計者はインターフェースに対する型パラメータの多様性を考慮する必要はありませんが、代わりに複雑なメソッドシグネチャを使用する必要が生じることがよくあります。一般的な例として、インターフェースが挙げられますComparable。^{[ 3 ]}^{: 66}コレクション内の最大の要素を見つける関数を作成したいとします。要素はメソッドを実装する必要があります。^[³^]^:⁶⁶したがって、最初の試みは次のようになります。compareTo

< T extends Comparable < T >> T max ( Collection < T > coll );

しかし、この型は汎用性が十分ではありません。の最大値は見つけることができますが、の最大値は見つけられません。問題は、がを実装していないことです。代わりに、(より優れた) インターフェースを実装しています。Java では、C# とは異なり、はのサブタイプとはみなされません。代わりに、の型を変更する必要があります。Collection<Calendar>Collection<GregorianCalendar>GregorianCalendarComparable<GregorianCalendar>Comparable<Calendar>Comparable<Calendar>Comparable<GregorianCalendar>max

< T extends Comparable <? super T >> T max ( Collection < T > coll );

境界付きワイルドカードは、インターフェースから反変メソッドのみを呼び出すという情報を伝えます。この特定の例は、内のすべてのメソッドが反変であるため、その条件が自明に真となるため、煩雑です。宣言サイトシステムであれば、の定義のみに注釈を付けることで、この例をより簡潔に処理できます。?superTmaxComparableComparableComparable

メソッドパラメータに上限付きワイルドカードを使用することで、メソッドをさらに変更できます。^[¹⁷^]max

< T extends Comparable <? super T >> T max ( Collection <? extends T > coll );

宣言サイト注釈と使用サイト注釈の比較

使用箇所における差異注釈は、柔軟性を高め、より多くのプログラムで型チェックを可能にする。しかしながら、言語の複雑さを増大させ、複雑な型シグネチャやエラーメッセージにつながるという批判もある。

追加の柔軟性が有用かどうかを評価する一つの方法は、既存のプログラムで使用されているかどうかを確認することです。多数のJavaライブラリ^{[ 15 ]}の調査では、ワイルドカード注釈の39%が宣言サイト注釈で直接置き換えることができたことがわかりました。したがって、残りの61%は、Javaが使用サイトシステムを利用することで恩恵を受ける場所を示しています。

宣言サイト言語では、ライブラリは、より少ないバリアンスを公開するか、より多くのインターフェースを定義する必要があります。たとえば、Scala Collections ライブラリは、共変性を使用するクラスに対して 3 つの別々のインターフェースを定義しています。共通メソッドを含む共変ベースインターフェース、副作用のあるメソッドを追加する不変可変バージョン、および構造的共有を利用するために継承された実装を特殊化できる共変不変バージョンです。^{[ 18 ]}この設計は宣言サイト注釈とうまく機能しますが、インターフェースの数が多いため、ライブラリのクライアントにとって複雑さのコストがかかります。また、ライブラリのインターフェースを変更することは選択肢にならない場合があります。特に、Java にジェネリクスを追加したときの目標の 1 つは、バイナリの後方互換性を維持することでした。

一方、Java のワイルドカード自体が複雑です。会議での発表^{[ 19 ]}で、 Joshua Bloch は、理解と使用が難しすぎると批判し、クロージャのサポートを追加する際には「もうワイルドカードを追加する余裕はない」と述べています。Scala の初期バージョンでは使用箇所のバリアンス注釈が使用されていましたが、プログラマーは実際に使用するのが難しいと感じていました。一方、宣言箇所の注釈はクラスの設計時に非常に役立つことがわかりました。^{[ 20 ]} Scala の後のバージョンでは、Java スタイルの存在型とワイルドカードが追加されましたが、Martin Oderskyによると、Java との相互運用性が必要なければ、これらは含まれなかっただろうとのことです。^{[ 21 ]}

Ross Tate は^{[ 22 ]}、Java のワイルドカードの複雑さの一部は、存在型の一種を使用して使用箇所の差異をエンコードするという決定によるものだと主張している。元の提案^{[ 23 ]}^{[ 24 ]}では、差異注釈に専用の構文を使用し、Java のより冗長なの代わりにと記述していた。List<+Animal>List<?extendsAnimal>

ワイルドカードは存在型の一種であるため、可変性以外にも様々な用途に使用できます。例えば、("不明な型のリスト" ^[²⁵^] ) のような型を使用すると、型パラメータを正確に指定することなく、オブジェクトをメソッドに渡したり、フィールドに格納したりできます。これは、ほとんどのメソッドで型パラメータが言及されていないクラスなどで特に役立ちます。List<?>Class

しかし、存在型の型推論は難しい問題です。コンパイラ実装者にとって、Javaのワイルドカードは型チェッカーの終了、型引数の推論、および曖昧なプログラムといった問題を引き起こします。^{[ 26 ]}一般に、ジェネリクスを使用するJavaプログラムが型付けされているかどうかは決定不能であるため、 ^{[ 27 ]}型チェッカーは一部のプログラムで無限ループに陥るかタイムアウトする必要があります。プログラマにとっては、複雑な型エラーメッセージにつながります。Javaはワイルドカードを新しい型変数に置き換えることでワイルドカード型の型チェックを行います（いわゆるキャプチャ変換）。これにより、エラーメッセージがプログラマが直接記述していない型変数を参照するため、エラーメッセージが読みにくくなることがあります。たとえば、をに追加しようとすると、次のようなエラーが発生します。CatList<?extendsAnimal>

メソッド List.add (capture#1) は適用できません (実際の引数Catは、メソッド呼び出し変換によってcapture#1に変換できません) ここで、capture#1 は新しい型変数です。 capture#1 は、キャプチャから Animal を拡張します。? は Animal を拡張します。

宣言サイト注釈と使用サイト注釈の両方が有用であるため、一部の型システムでは両方を提供しています。^{[ 15 ]}^{[ 22 ]}

注記

↑これは病的な場合にのみ発生します。たとえば、I<T> = int: には任意の型を入れることができますTが、結果は依然としてですint。

参考文献

1 2 3 Skeet, Jon (2019年3月23日). C# in Depth . Manning. ISBN 978-1617294532。
↑ Func<T, TResult> デリゲート- MSDN ドキュメント
1 2 3 4 5 6 7 8 Bloch, Joshua (2018). "Effective Java: Programming Language Guide" (第3版). Addison-Wesley. ISBN 978-0134685991。
↑レイノルズ、ジョン C. (1981). Algol の本質。アルゴリズム言語に関するシンポジウム。ノースホランド。
↑カルデッリ、ルカ (1984).多重継承のセマンティクス(PDF) . データ型のセマンティクス (国際シンポジウム、ソフィア・アンティポリス、フランス、1984年6月27日～29日). コンピュータサイエンス講義録。第173巻。Springer。pp. 51–67。doi : 10.1007 /3-540-13346-1_2。ISBN 3-540-13346-1。より長いバージョン: — (1988 年 2月) 「多重継承のセマンティクス」。Information and Computation。76 ( 2/3): 138–164。CiteSeerX 10.1.1.116.1298。doi : 10.1016 /0890-5401(88) 90007-7 。
↑トーガーセン、マッツ。「記録上の C# 9.0」。
↑アリソン、チャック。「標準C++の新機能とは？」。
↑ 「一般的な型の問題を修正する」 . Dart プログラミング言語.
↑ Bertrand Meyer (1995 年 10 月)。「静的型付け」(PDF)。OOPSLA 95 (オブジェクト指向プログラミング、システム、言語、アプリケーション)、アトランタ、1995 年。
1 2 Howard, Mark; Bezault, Eric; Meyer, Bertrand; Colnet, Dominique; Stapf, Emmanuel; Arnout, Karine; Keller, Markus (2003 年 4 月) 「型安全な共変性: 有能なコンパイラはすべての catcall を検出できます」(PDF) 。2013年5 月 23 日に取得。
↑ Franz Weber (1992). "クラスの正しさとシステムの正しさを同等にする - 共変性を正しく取得する方法". TOOLS 8 (オブジェクト指向言語とシステムの技術に関する第 8 回会議)、ドルトムント、1992 年。CiteSeerX 10.1.1.52.7872。
↑ Castagna, Giuseppe (1995 年 5 月). "共変性と反変性: 原因なき衝突". ACM Transactions on Programming Languages and Systems . 17 (3): 431–447 . CiteSeerX 10.1.1.115.5992 . doi : 10.1145/203095.203096 . S2CID 15402223 .
↑ Lippert, Eric (2009年12月3日). 「分散妥当性に関する正確なルール」 . 2016年8月16日取得。
↑「セクション II.9.7」。ECMA国際標準 ECMA-335 共通言語インフラストラクチャ (CLI) (第 6版)。2012 年 6 月。
1 2 3 Altidor, John; Shan, Huang Shan; Smaragdakis, Yannis (2011). "ワイルドカードの扱い方：定義サイトと使用サイトの差異の組み合わせ".第32回ACM SIGPLANプログラミング言語設計実装会議（PLDI'11）議事録. ACM. pp. 602–613 . CiteSeerX 10.1.1.225.8265 . doi : 10.1145/1993316.1993569 . ISBN 9781450306638。
↑ Lippert, Eric (2007 年 10 月 29 日). "C# における共変性と反変性パート 7: なぜ構文が必要なのか?" . 2016 年8 月 16 日に取得。
↑ Bloch 2018、pp. 139–145、第 5 章項目 31: API の柔軟性を高めるために、境界付きワイルドカードを使用する。
↑ Odersky, Marin; Spoon, Lex (2010年9月7日). "The Scala 2.8 Collections API" . 2016年8月16日取得。
↑ Bloch, Joshua (2007年11月)。「閉鎖論争[ビデオ]」。Javapolis'07でのプレゼンテーション。 2014年2月2日にオリジナルからアーカイブ済み。{{cite web}}: CS1メンテナンス: 場所 (リンク)
↑ Odersky, Martin; Zenger, Matthias (2005). "スケーラブルなコンポーネント抽象化" (PDF) .第20回ACM SIGPLANオブジェクト指向プログラミング、システム、言語、アプリケーションに関する年次会議（OOPSLA '05）議事録. ACM. pp. 41–57 . CiteSeerX 10.1.1.176.5313 . doi : 10.1145/1094811.1094815 . ISBN 1595930310。
↑ Venners, Bill; Sommers, Frank (2009 年 5 月 18 日). "Scala の型システムの目的: Martin Odersky との対話、パート III" . 2016 年8 月 16 日に取得。
1 2 Tate, Ross (2013). "Mixed-Site Variance" . FOOL '13: Informal Proceedings of the 20th International Workshop on Foundations of Object-Oriented Languages . CiteSeerX 10.1.1.353.4691 .
↑五十嵐篤、ミルコ・ヴィロリ (2002)「パラメトリック型に対するバリアンスベースのサブタイピングについて」第16回欧州オブジェクト指向プログラミング会議（ECOOP '02）論文集、Lecture Notes in Computer Science、第2374巻、 441–469頁、 CiteSeerX 10.1.1.66.450、doi : 10.1007/3-540-47993-7_19、ISBN 3-540-47993-7。
↑ Thorup, Kresten Krab; Torgersen, Mads (1999). "Unifying Genericity: Combining the Benefits of Virtual Types and Parameterized Classes". Object-Oriented Programming (ECOOP '99) . Lecture Notes in Computer Science. Vol. 1628. Springer. pp. 186–204 . CiteSeerX 10.1.1.91.9795 . doi : 10.1007/3-540-48743-3_9 . ISBN 3-540-48743-3。
↑ 「Java™ チュートリアル、ジェネリクス（更新版）、無制限のワイルドカード」。 2020年7月17日取得。
↑ Tate, Ross; Leung, Alan; Lerner, Sorin (2011). "Javaの型システムにおけるワイルドカードの扱い方" .第32回ACM SIGPLANプログラミング言語設計実装会議（PLDI '11）議事録. pp. 614–627 . CiteSeerX 10.1.1.739.5439 . ISBN 9781450306638。
↑ Grigore, Radu (2017). "Javaのジェネリクスはチューリング完全である".第44回ACM SIGPLANプログラミング言語原理シンポジウム（POPL'17）論文集. pp. 73–85 . arXiv : 1605.05274 . Bibcode : 2016arXiv160505274G . ISBN 9781450346603。

外部リンク

共変性と反変性 - コーディングの素晴らしき冒険：C# における共変性／反変性に関する実装上の懸念事項についてのエリック・リッパートによる記事シリーズ。（2008 年にMSDNからアーカイブされたもの。一部の記事は現在も彼の個人サイトで閲覧可能。このアーカイブには 2019 年の記事も多数収録されている。）
Contra VarianceとCo Varianceの比較（注：この記事はC++に関する最新情報は提供していません）
Java 7プログラミング言語のためのクロージャ（v0.5）
C# 4における共変性と反変性の理論

[1] これは病的な場合にのみ発生します。たとえば、I<T> = int: には任意の型を入れることができますTが、結果は依然としてですint。

[Skeet-2] 1 2 3 Skeet, Jon (2019年3月23日). C# in Depth . Manning. ISBN 978-1617294532。

[3] Func<T, TResult> デリゲート- MSDN ドキュメント

[Bloch-4] 1 2 3 4 5 6 7 8 Bloch, Joshua (2018). "Effective Java: Programming Language Guide" (第3版). Addison-Wesley. ISBN 978-0134685991。

[5] レイノルズ、ジョン C. (1981). Algol の本質。アルゴリズム言語に関するシンポジウム。ノースホランド。

[6] カルデッリ、ルカ (1984).多重継承のセマンティクス(PDF) . データ型のセマンティクス (国際シンポジウム、ソフィア・アンティポリス、フランス、1984年6月27日～29日). コンピュータサイエンス講義録。第173巻。Springer。pp. 51–67。doi : 10.1007 /3-540-13346-1_2。ISBN 3-540-13346-1。より長いバージョン: — (1988 年 2月) 「多重継承のセマンティクス」。Information and Computation。76 ( 2/3): 138–164。CiteSeerX 10.1.1.116.1298。doi : 10.1016 /0890-5401(88) 90007-7 。

[7] トーガーセン、マッツ。「記録上の C# 9.0」。

[8] アリソン、チャック。「標準C++の新機能とは？」。

[Fixing_Common_Type_Problems_|_Dart-9] 「一般的な型の問題を修正する」 . Dart プログラミング言語.

[10] Bertrand Meyer (1995 年 10 月)。「静的型付け」(PDF)。OOPSLA 95 (オブジェクト指向プログラミング、システム、言語、アプリケーション)、アトランタ、1995 年。

[competentCompilers-11] 1 2 Howard, Mark; Bezault, Eric; Meyer, Bertrand; Colnet, Dominique; Stapf, Emmanuel; Arnout, Karine; Keller, Markus (2003 年 4 月) 「型安全な共変性: 有能なコンパイラはすべての catcall を検出できます」(PDF) 。2013年5 月 23 日に取得。

[12] Franz Weber (1992). "クラスの正しさとシステムの正しさを同等にする - 共変性を正しく取得する方法". TOOLS 8 (オブジェクト指向言語とシステムの技術に関する第 8 回会議)、ドルトムント、1992 年。CiteSeerX 10.1.1.52.7872。

[13] Castagna, Giuseppe (1995 年 5 月). "共変性と反変性: 原因なき衝突". ACM Transactions on Programming Languages and Systems . 17 (3): 431–447 . CiteSeerX 10.1.1.115.5992 . doi : 10.1145/203095.203096 . S2CID 15402223 .

[14] Lippert, Eric (2009年12月3日). 「分散妥当性に関する正確なルール」 . 2016年8月16日取得。

[15] 「セクション II.9.7」。ECMA国際標準 ECMA-335 共通言語インフラストラクチャ (CLI) (第 6版)。2012 年 6 月。

[tamingCombining-16] 1 2 3 Altidor, John; Shan, Huang Shan; Smaragdakis, Yannis (2011). "ワイルドカードの扱い方：定義サイトと使用サイトの差異の組み合わせ".第32回ACM SIGPLANプログラミング言語設計実装会議（PLDI'11）議事録. ACM. pp. 602–613 . CiteSeerX 10.1.1.225.8265 . doi : 10.1145/1993316.1993569 . ISBN 9781450306638。

[17] Lippert, Eric (2007 年 10 月 29 日). "C# における共変性と反変性パート 7: なぜ構文が必要なのか?" . 2016 年8 月 16 日に取得。

[FOOTNOTEBloch2018139–145Chapter_§5_Item_31:_Use_bounded_wildcards_to_increase_API_flexibility-18] Bloch 2018、pp. 139–145、第 5 章項目 31: API の柔軟性を高めるために、境界付きワイルドカードを使用する。

[19] Odersky, Marin; Spoon, Lex (2010年9月7日). "The Scala 2.8 Collections API" . 2016年8月16日取得。

[20] Bloch, Joshua (2007年11月)。「閉鎖論争[ビデオ]」。Javapolis'07でのプレゼンテーション。 2014年2月2日にオリジナルからアーカイブ済み。{{cite web}}: CS1メンテナンス: 場所 (リンク)

[21] Odersky, Martin; Zenger, Matthias (2005). "スケーラブルなコンポーネント抽象化" (PDF) .第20回ACM SIGPLANオブジェクト指向プログラミング、システム、言語、アプリケーションに関する年次会議（OOPSLA '05）議事録. ACM. pp. 41–57 . CiteSeerX 10.1.1.176.5313 . doi : 10.1145/1094811.1094815 . ISBN 1595930310。

[22] Venners, Bill; Sommers, Frank (2009 年 5 月 18 日). "Scala の型システムの目的: Martin Odersky との対話、パート III" . 2016 年8 月 16 日に取得。

[MixedSiteVariance-23] 1 2 Tate, Ross (2013). "Mixed-Site Variance" . FOOL '13: Informal Proceedings of the 20th International Workshop on Foundations of Object-Oriented Languages . CiteSeerX 10.1.1.353.4691 .

[24] 五十嵐篤、ミルコ・ヴィロリ (2002)「パラメトリック型に対するバリアンスベースのサブタイピングについて」第16回欧州オブジェクト指向プログラミング会議（ECOOP '02）論文集、Lecture Notes in Computer Science、第2374巻、 441–469頁、 CiteSeerX 10.1.1.66.450、doi : 10.1007/3-540-47993-7_19、ISBN 3-540-47993-7。

[25] Thorup, Kresten Krab; Torgersen, Mads (1999). "Unifying Genericity: Combining the Benefits of Virtual Types and Parameterized Classes". Object-Oriented Programming (ECOOP '99) . Lecture Notes in Computer Science. Vol. 1628. Springer. pp. 186–204 . CiteSeerX 10.1.1.91.9795 . doi : 10.1007/3-540-48743-3_9 . ISBN 3-540-48743-3。

[26] 「Java™ チュートリアル、ジェネリクス（更新版）、無制限のワイルドカード」。 2020年7月17日取得。

[27] Tate, Ross; Leung, Alan; Lerner, Sorin (2011). "Javaの型システムにおけるワイルドカードの扱い方" .第32回ACM SIGPLANプログラミング言語設計実装会議（PLDI '11）議事録. pp. 614–627 . CiteSeerX 10.1.1.739.5439 . ISBN 9781450306638。

[28] Grigore, Radu (2017). "Javaのジェネリクスはチューリング完全である".第44回ACM SIGPLANプログラミング言語原理シンポジウム（POPL'17）論文集. pp. 73–85 . arXiv : 1605.05274 . Bibcode : 2016arXiv160505274G . ISBN 9781450346603。

[

[

[

[ 3 ]

[ 4 ]

[

[ 6 ]

[ 7 ]

[ 8 ]

[

[

[ 11 ]

[ 12 ]は

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]、

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[

[ 26 ]

[ 27 ]