共変性と反変性（コンピュータサイエンス）

多くのプログラミング言語の 型システムは、 のサブタイプをサポートしています。たとえば、型 Catが のサブタイプである場合Animal、型の式が使用されている場所では、型の式Cat が置換可能である必要がありますAnimal。

分散とは、より複雑な型間のサブタイプ化が、そのコンポーネント間のサブタイプ化とどのように関連しているかということです。たとえば、のリストはCatのリストとどのように関連しているべきでしょうか。または、を返す関数は、 を返す関数とAnimalどのように関連しているべきでしょうか。 CatAnimal

型コンストラクタの可変性に応じて、それぞれの複合型に対して、単純型のサブタイプ関係が保持されるか、反転されるか、無視されるかのいずれかになります。たとえば、 OCamlプログラミング言語では、リスト型コンストラクタが共変であるため、「Cat のリスト」は「Animal のリスト」のサブタイプです。つまり、単純型のサブタイプ関係は複合型に対して保持されます。

一方、「Animal から String への関数」は、関数の型コンストラクタがパラメータ型に対して反変であるため、「Cat から String への関数」のサブタイプです。ここでは、単純型のサブタイプ関係が複合型に対して逆になっています。

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

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

Aと が型でありB、 が型引数 を持つ型コンストラクタI<U>の適用を表すとします。プログラミング言語の型システムでは、型コンストラクタの型付け規則は次のとおりです。 IUI

• 型の順序 (≤)が保存される場合は共変であり、型はより具体的なものからより一般的なものの順に並べられます。 の場合A ≤ B、 です I<A> ≤ I<B>。
• この順序を逆にすると反変になりますA ≤ B。 の場合、 となり ますI<B> ≤ I<A>。
• これら両方が当てはまる場合（つまり、A ≤ Bの場合、 ）は二変であるI<A> ≡ I<B>。^[1]
• 共変、反変、または双変の場合はvariant 。
• 不変、またはバリアントでない場合は非バリアント。

この記事では、これがいくつかの一般的な型コンストラクターにどのように適用されるかを検討します。

たとえば、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# ジェネリック インターフェイスの変性は、out(共変) またはin(反変) 属性をその型パラメーター (の 0 個以上) に配置することによって宣言されます。^{[2] : 144}上記のインターフェイスは、、、およびとして宣言されます。複数の型パラメーターを持つ型では、各型パラメーターに異なる変性を指定できます。たとえば、デリゲート型は、反変の入力パラメーター型と共変の戻り値型を持つ関数を表します。^{[3] [2] : 145}コンパイラは、すべての型が定義され、注釈と一貫して使用されていることを確認し、そうでない場合はコンパイル エラーを通知します。 IEnumerable<out T>Action<in T>IList<T>Func<in T, out TResult>TTResult

インターフェースの変異の型付け規則は型の安全性を保証します。たとえば、は型の引数を期待する第一級関数を表します。^{[2] : 144}また、猫だけを処理できる関数の代わりに、任意の種類の動物を処理できる関数を常に使用できます。 Action<T>T

読み取り専用データ型 (ソース) は共変にすることができ、書き込み専用データ型 (シンク) は反変にすることができます。ソースとシンクの両方の役割を果たす可変データ型は不変である必要があります。この一般的な現象を説明するために、配列型について考えてみましょう。 型 に対して、 "動物の配列" であるAnimal型 を作成できます。この例では、この配列は要素の読み取りと書き込みの両方をサポートします。 Animal[]

これを次のいずれかとして扱うオプションがあります。

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

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

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

Java と C# の初期バージョンには、ジェネリック(パラメトリック ポリモーフィズムとも呼ばれる) は含まれていませんでした。このような設定では、配列を不変にすると、有用なポリモーフィック プログラムが排除されます。

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

ブール型のequalArrays ( Object [] a1 、Object [] a2 ); void shuffleArray ( Object [] a );    
  

ただし、配列型が不変として扱われる場合、これらの関数は正確に 型の配列に対してのみ呼び出すことができます。たとえば、文字列の配列をシャッフルすることはできません。 Object[]

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

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

// a は文字列の単一要素配列です。String [] a = new String [ 1 ] ;    


// b はオブジェクトの配列です。Object [] b = a ;   


// b に Integer を割り当てます。これは、 bが実際にObject の配列
である場合は可能ですが、実際には String の配列であるため、 java.lang.ArrayStoreException が発生します。b 
[ 0 ] = 1 ;  

上記の例では、配列 (b) から安全に読み取ることができます。問題が発生する可能性があるのは、配列に 書き込もうとした場合のみです。

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

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

< T >ブール型の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 に置き換えても安全です。たとえば、、、型の関数は、 a が期待される場所であればどこでも使用できます。(これは、コミュニケーションの堅牢性の原則、「受け入れるものには寛大に、生成するものには保守的に」に似ています。)一般的なルールは次のとおりです。 animal -> catcat -> catanimal -> animalcat -> animal

${\displaystyle (P_{1}\rightarrow R_{1})\leq (P_{2}\rightarrow R_{2})}$かつ の場合。${\displaystyle P_{1}\geq P_{2}}$${\displaystyle R_{1}\leq R_{2}}$

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

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

言い換えれば、→型コンストラクタはパラメータ（入力）型に対して反変であり、戻り値（出力）型に対して共変である。この規則は、John C. Reynolds ^[5]によって最初に正式に述べられ、 Luca Cardelli ^[6]の論文でさらに普及した。

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

サブクラスがスーパークラスのメソッドをオーバーライドする場合、コンパイラはオーバーライドするメソッドの型が正しいかどうかをチェックする必要があります。一部の言語では、型がスーパークラスの型と完全に一致する必要があります (不変性) が、オーバーライドするメソッドの型が「より適切な」型であっても、型安全です。関数型の通常のサブタイプ規則では、オーバーライドするメソッドはより具体的な型を返し (戻り値の型の共変性)、より一般的な引数を受け入れる必要があります (パラメーターの型の反変性)。UML 表記では、次のようになります (クラス B は、スーパークラスであるクラス A を拡張するサブクラスです)。

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

具体的な例として、動物保護施設をモデル化するクラスを書いているとします。Catは のサブクラスでありAnimal、基本クラス（Java構文を使用）があると 仮定します。

クラス AnimalShelter { 

    Animal getAnimalForAdoption () { // ... } void putAnimal ( Animal ) { // ... } }  
        
    
    
       
        
    

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

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

クラス CatShelterはAnimalShelterを拡張します{   

    Cat getAnimalForAdoption () { return new Cat (); } }  
          
    

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

同様に、オーバーライド メソッドが基本クラスのメソッドよりも一般的な引数を受け入れるようにすることは、型安全です。

クラス CatShelter はAnimalShelter を拡張します{ void putAnimal ( Object animal ) { // ... } }   
       
        
    

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

ただし、Sather は共変性と反変性の両方をサポートしていました。オーバーライドされたメソッドの呼び出し規約は、outパラメータと戻り値とは共変性であり、通常のパラメータとは反変性です (モードはin )。

主流の言語であるEiffelとDart ^[9]では、オーバーライドメソッドのパラメータがスーパークラスのメソッドよりもputAnimal特定の型を持つことを許可しています（パラメータ型の共変性）。したがって、次のDartコードは、基本クラスのメソッドをオーバーライドし て型チェックを行います。

クラスCatShelterはAnimalShelterを拡張します{    

    void putAnimal (共変Cat animal ) { // ... } }    
        
    

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

型の安全性の問題にもかかわらず、Eiffelの設計者は、共変パラメータ型が現実世界の要件をモデル化する上で重要であると考えています。^[11]猫のシェルターは、一般的な現象を示しています。これは一種の動物シェルターですが、追加の制限があり、これをモデル化するには継承と制限されたパラメータ型を使用するのが合理的であると思われます。継承のこの使用法を提案する際に、Eiffelの設計者は、サブクラスのオブジェクトは常にスーパークラスのオブジェクトよりも制限が緩い必要があるという リスコフの置換原則を拒否しています。

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

インターフェース AnimalInterface  {}


インターフェース DogInterface は AnimalInterfaceを拡張します {} 


 Dog クラスはDogInterface {}を実装します。  


クラス Pet 
{
    パブリック 関数 __construct ( AnimalInterface  $animal )  {} 
}


クラス PetDog は Petを拡張します { public関数__construct ( DogInterface $dog ) {親:: __construct ( $dog ); } }

       
    
        
    

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

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

インターフェース Comparable { 

    int compareTo (オブジェクトo ); }  

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

クラス RationalNumber はComparableを実装します{ int分子; int分母; // ... public int compareTo ( Object other ) { RationalNumber otherNum = ( RationalNumber ) other ; return Integer.compare (分子* otherNum .分母, otherNum .分子*分母); } }   
     
     
    
 
        
           
           
                                 
    

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

他の言語機能は、リスコフの代替可能性を維持しながら、共変パラメータの明らかな利点を提供できます。

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

クラス Shelter < T extends Animal > {   

    T getAnimalForAdoption () { // ... }  
        
    

    void putAnimal ( T動物) { // ... } }   
        
    


    
クラス CatShelter はShelter < Cat >を拡張します{   

    猫getAnimalForAdoption () { // ... }  
        
    

    void putAnimal (猫の動物) { // ... } }   
        
    

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

クラス RationalNumber はComparable < RationalNumber >を実装します{   

    int分子; int分母; // ... public int compareTo ( RationalNumber otherNum ) { return Integer.compare (分子* otherNum .分母, otherNum .分子*分母) ; } } 
     
    
         
        
            
                                 
    

役に立つもう 1 つの言語機能は、多重ディスパッチです。バイナリ メソッドの記述が扱いにくい理由の 1 つは、 のような呼び出しでは、 の正しい実装の選択が実際にはと の両方のランタイム タイプに依存することですが、従来の OO 言語では のランタイム タイプのみが考慮されます。Common Lisp Object System (CLOS) スタイルの多重ディスパッチ を持つ言語では、比較メソッドは、両方の引数をメソッド選択に使用する汎用関数として記述できます。 a.compareTo(b)compareToaba

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

Castagna は、共変パラメータ型が優れている例 (特にバイナリ メソッド) は、自然に共変である多重ディスパッチを使用して処理する必要があることを提案しています。ただし、ほとんどのプログラミング言語は多重ディスパッチをサポートしていません。

次の表は、上で説明した言語でメソッドをオーバーライドするためのルールをまとめたものです。

ジェネリック (別名パラメトリック多態性)をサポートするプログラミング言語では、プログラマーは新しいコンストラクターを使用して型システムを拡張できます。たとえば、 のような C# インターフェースを使用すると、やのような新しい型を構築できます。ここで、これらの型コンストラクターの分散はどうあるべきかという疑問が生じます。 IList<T>IList<Animal>IList<Cat>

主なアプローチは 2 つあります。宣言サイトの差異注釈を持つ言語(例: C# ) では、プログラマーはジェネリック型の定義に、その型パラメーターの意図された差異を注釈します。使用サイトの差異注釈(例: Java ) では、プログラマーは代わりにジェネリック型がインスタンス化される場所に注釈を付けます。

宣言サイトの変異注釈を持つ最も一般的な言語は、C#とKotlin (キーワードoutと を使用in)、およびScalaとOCaml (キーワード+と を使用-) です。C# では、インターフェース型に対してのみ変異注釈が許可されますが、Kotlin、Scala、および OCaml では、インターフェース型と具体的なデータ型の両方に対して変異注釈が許可されます。

C# では、ジェネリック インターフェイスの各型パラメータは、共変 ( out)、反変 ( in)、または不変 (注釈なし) としてマークできます。たとえば、読み取り専用反復子のインターフェイスを定義し、その型パラメータで共変 (out) として宣言できます。 IEnumerator<T>

インターフェイスIEnumerator < out T > { TCurrent { get ; } boolMoveNext ( ) ; }  

        
     

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

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

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

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

インターフェイス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]

シール抽象クラスList [ + A ]は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]

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

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

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

タイプ ( ' a ,  ' b )  t  =  T  of  ( ' a  ->  ' b )

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

タイプ (- ' a 、 + ' b )  t  =  T  of  ( ' a  ->  ' b )

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

モジュール 型 S  = 
    sig
        型 key
        型 (+ ' a )  t 
        val  empty :  ' a  t 
        val  mem :  key  ->  ' a  t  ->  bool 
        ...
    終了

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

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

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

Javaは、境界付き存在型の制限された形式であるワイルドカードを通じて、使用部位の変異注釈を提供します。パラメータ化された型は、またはのように、上限または下限とともにワイルドカードによってインスタンス化できます。 のような境界なしワイルドカードはと同等です。このような型は、境界を満たす未知の型を表します。 ^{[4] : 139}たとえば、 が型 である場合、型チェッカーは を受け入れます。 ?List<? extends Animal>List<? super Animal>List<?>List<? extends Object>List<X>XlList<? extends Animal>

動物a = l.get ( 3 ) ;​   

型はXのサブタイプであることがわかっているAnimalが、

l.add (新しいAnimal ( ) ) ; 

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

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

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

一般的なデータ構造の場合IList、共変パラメータは構造からデータを取得するメソッドに使用され、反変パラメータは構造にデータを入れるメソッドに使用されます。Joshua Bloch 著のEffective Javaに出てくる Producer Extends, Consumer Super (PECS) の記憶法は、共変と反変をいつ使用するかを簡単に覚える方法を示しています。^{[4] : 141}

ワイルドカードは柔軟性に優れていますが、欠点もあります。使用場所の差異により、API設計者はインターフェースの型パラメータの差異を考慮する必要がなくなりますが、代わりにより複雑なメソッドシグネチャを使用する必要があります。一般的な例として、インターフェースがありますComparable。^{[4] : 66}コレクション内の最大の要素を検索する関数を記述するとします。要素はcompareToメソッドを実装する必要があるため、^{[4] : 66}最初の試みは次のようになります。

< T はComparable < T >> T max ( Collection < T > coll )を拡張します。     

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

< T はComparable <? super T >> T max ( Collection < T > coll )を拡張します。       

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

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

< T はComparable <? super T >> T max (コレクション<? extends T > coll )を拡張します。         

使用サイト変異注釈は柔軟性を高め、より多くのプログラムが型チェックできるようにします。ただし、言語に複雑さを追加し、複雑な型署名とエラー メッセージにつながるという批判もあります。

追加の柔軟性が有用かどうかを評価する 1 つの方法は、既存のプログラムで使用されているかどうかを確認することです。大規模な Java ライブラリ セットの調査^[16]では、ワイルドカード注釈の 39% が宣言サイト注釈に直接置き換えられる可能性があることがわかりました。したがって、残りの 61% は、Java が使用サイト システムを利用できることでメリットを得られる場所を示しています。

宣言サイト言語では、ライブラリはより少ない分散を公開するか、より多くのインターフェースを定義する必要があります。たとえば、Scala Collections ライブラリは、共変性を採用するクラスに対して 3 つの個別のインターフェースを定義します。共通メソッドを含む共変性基本インターフェース、副作用メソッドを追加する不変可変バージョン、および構造共有を活用するために継承された実装を特殊化できる共変性不変バージョンです。^[19]この設計は宣言サイト注釈ではうまく機能しますが、多数のインターフェースはライブラリのクライアントに複雑さのコストをもたらします。また、ライブラリ インターフェースを変更することはオプションではない可能性があります。特に、Java にジェネリックを追加する際の目標の 1 つは、バイナリの下位互換性を維持することでした。

一方、Java のワイルドカードは複雑です。カンファレンスのプレゼンテーション^[20]で、 Joshua Bloch は、ワイルドカードは理解しにくく、使用するのが難しいと批判し、クロージャのサポートを追加する際には「ワイルドカードを追加する余裕はない」と述べました。Scalaの初期バージョンでは、使用場所のバリアンス アノテーションを使用していましたが、プログラマーは実際には使いにくいと感じました。一方、宣言場所のアノテーションは、クラスを設計する際に非常に役立つことがわかりました。^[21] Scala の後のバージョンでは、Java スタイルの存在型とワイルドカードが追加されましたが、Martin Oderskyによると、Java との相互運用性が必要でなければ、これらはおそらく含まれていなかったでしょう。^[22]

ロス・テイトは^[23]、Javaワイルドカードの複雑さの一部は、使用場所の差異を存在型の形式を使用してエンコードするという決定によるものだと主張している。当初の提案^{[24] [25]}では、差異注釈に特殊な構文が使用され、Javaのより冗長な の代わりに が書かれていた。 List<+Animal>List<? extends Animal>

ワイルドカードは存在型の一種であるため、単なる変異以外にもさまざまな用途に使用できます。(「未知の型のリスト」^[26] )のような型を使用すると、型パラメータを正確に指定せずにオブジェクトをメソッドに渡したり、フィールドに格納したりできます。これは、ほとんどのメソッドが型パラメータに言及していない クラスなどで特に役立ちます。List<?>Class

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

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

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

これらの用語は、圏論における共変および反変の関手の概念に由来します。オブジェクトが型であり、射がサブタイプ関係 ≤ を表す圏を考えます。(これは、任意の半順序集合を圏として考えることができる例です。) 次に、たとえば関数型コンストラクタは 2 つの型pとrを受け取り、新しい型p → rを作成します。つまり、 のオブジェクトを のオブジェクトに取り込みます。関数型のサブタイプ規則により、この操作は最初のパラメータの ≤ を反転し、2 番目のパラメータに対してそれを保持するため、最初のパラメータでは反変の関手、2 番目のパラメータでは共変の関手になります。 ${\displaystyle C}$${\displaystyle C^{2}}$${\displaystyle C}$

• ポリモーフィズム（コンピュータサイエンス）
• 継承（オブジェクト指向プログラミング）
• リスコフの置換原理

• コーディングの素晴らしい冒険: C# の共変性/反変性に関する実装上の懸念についての記事シリーズ
• 反対分散と共分散 (この記事は C++ については更新されていないことに注意してください)
• Java 7 プログラミング言語のクロージャ (v0.5)
• C# 4 における共変性と反変性の理論