invariant

以下のように捉えると直観に沿う

readする時は、covariantが必要

writeする時は、contravariantが必要

read/writeの両方を持ち合わせているものは、invariantである必要がある

例

部分型関係が全く無い

だから、どちらかを、もう一方に代入するなんてことはできなくなる

Arrayにおけるwriteが共変だったらどういう問題が起きるのか？

以下のようなコードが書けてしまう

code:scala

arr2(0) = 4.2

参照を持っているから

実際はScalaのArrayはinvariantなのでちゃんとコンパイルエラーになる

code:scala

// Listは共変

// Arrayは不変

arr2(0) = 4.2

他の例

code:scala

add(arr) // error

TypeScriptのArrayはcovariantになっている

そのため健全性が壊れている

JavaもそうだとTaPLに書かれている

そのため、Javaは任意の配列の全ての破壊的代入においてruntime検査を行う

そのため、パフォーマンスが犠牲になっているらしい

参考

Kotlinのcovaritnとinvariantについて

つまり、共変になる

反変になる

TaPLのRefに対する説明をもじったもの

arr: Array<T> = [..]

arr[0] = t

a: S = arr[0]

こちらはcovariantである

こちらはcontravariantである

そして、以下の部分型関係が成り立つ

Ref T <: Source T

Ref T <: Sink T

kotlin

covariantにするためにoutつける

出力用にしか使われないことを明示する

contravariantにするためにinをつける

消費する用途にしか使われないことを明示する

何も付けないとinvariantになる

つまり、genericな関数の定義時に使う

code:kt

interface List<out E> : Collection<E> { ... }

interface MutableList<E> : List<E>, MutableCollection<E> { ... }

他の例

code:ts

type Animal = Cat | Dog;

type Cat = 'cat';

type Dog = 'dog';

add(cats);

参照とか絡まないのでノイズが少ない