= Solution
If the mutable <set> were allowed a <covariant type parameter>, both variables below could refer to the same mutable object:
``
val s1: Set[Int] = new Set[Int](List())
val s2: Set[Any] = s1 // hypothetically permitted
s2.add("not an integer")
val n: Int = s1.delete() // cannot return an Int
``
The broad view accepts any value, including a <string>. The narrow view still promises that deletion returns an `Int`, yet the sole stored value is that <string>. This violates <type safety>:
$$
\boxed{\text{A mutable collection that both accepts and returns }T\text{ cannot be covariant in }T.}
$$
This is <covariance failure for a mutable collection>. The input occurrence in `add(x: T)` conflicts with the positive occurrence in the result of `delete`. Keeping a <generic type invariance> restriction prevents the unsafe aliasing. The example uses an initially empty <set> so that the problematic deletion result is forced.
Back to article page
