has abstract
| - Many programming language type systems support subtyping. For instance, if the type <span class="n">Cat</span> is a subtype of <span class="n">Animal</span>, then an expression of type <span class="n">Cat</span> should be substitutable wherever an expression of type <span class="n">Animal</span> is used. Variance refers to how subtyping between more complex types relates to subtyping between their components. For example, how should a list of <span class="n">Cat</span>s relate to a list of <span class="n">Animal</span>s? Or how should a function that returns <span class="n">Cat</span> relate to a function that returns <span class="n">Animal</span>? Depending on the variance of the type constructor, the subtyping relation of the simple types may be either preserved, reversed, or ignored for the respective complex types. In the OCaml programming language, for example, "list of Cat" is a subtype of "list of Animal" because the list type constructor is covariant. This means that the subtyping relation of the simple types are preserved for the complex types. On the other hand, "function from Animal to String" is a subtype of "function from Cat to String" because the function type constructor is contravariant in the parameter type. Here the subtyping relation of the simple types is reversed for the complex types. A programming language designer will consider variance when devising typing rules for language features such as arrays, inheritance, and generic datatypes. By making type constructors covariant or contravariant instead of invariant, more programs will be accepted as well-typed. On the other hand, programmers often find contravariance unintuitive, and accurately tracking variance to avoid runtime type errors can lead to complex typing rules. In order to keep the type system simple and allow useful programs, a language may treat a type constructor as invariant even if it would be safe to consider it variant, or treat it as covariant even though that could violate type safety. (en)
|