Removal of covariance and contravariance

[raviqqe]

• Because they might be unnecessary complexity.
• Go is doing well (?) without it.
  • While it supports subtyping.
  • (user-defined type) <: (interface)
  • (interface) <: (interface)
• Function types would probably be fine as we can coerce the types easily when lambda expression added.
  • e.g. \x y -> f x y
• The most problematic part is List types.
  • Coerce types implicitly in list expressions?
  • The syntax looks like coercing types of each element one by one, which is consistent with the other non-function type subsumption.

xs : List Number

ys : List (Number | None)
ys = [ ...xs ] # valid

f : List (Number | None) -> None

z = f xs # type error because List Number /= List (Number | None)

Formulation

• Any generic types except union types would support neither covariance nor contravariance.

A | B <: C <=> A <: C && B <: C
A <: B | C <=> A == B || A == C 

References

• This will fix Broken covariance with union types #364.