What are type erasure and variance in generics, and how do Swift, Kotlin and Java differ?

Type erasure: Java and Kotlin check generic types at compile time and drop the type arguments in the bytecode. At runtime ArrayList<String> and ArrayList<Integer> are the same class, so you can’t write x instanceof List<String>, new T(), T.class, or two overloads that differ only by type argument, and JSON libraries need a TypeToken/TypeReference to learn that a list holds Users. Kotlin’s inline fun <reified T> keeps T at the call site. Swift keeps generic types at runtime and can specialize generic code per type.

Variance: if Cat is an Animal, may a container of cats be used as a container of animals?

• Reading only (producer): yes, that’s covariance. Kotlin: List<out E>. Java: List<? extends Animal>.
• Writing only (consumer): the other way round, contravariance. Kotlin: Comparator<in T>. Java: List<? super Cat>.
• Both: neither; invariant. MutableList<Cat> isn’t a MutableList<Animal>, or you could add a Dog to a list of cats.

Java’s rule of thumb is PECS, producer extends, consumer super. Swift generics are invariant, with the standard collections special-cased ([Cat] converts to [Animal] safely because arrays are values).

Senior bonus: Swift’s some P is one hidden concrete type checked statically, while any P is an existential box with dynamic dispatch and possible heap allocation, so prefer generics and some in hot code.