Still learning about generics. In this example I w...

# getting-started

[poohbar]

Still learning about generics. In this example I would expect this to work, because I feel like Animal<Int> fits into Animal<Any?>. What am I missing?

open class Animal<T>
class Dog: Animal<Int>()
val x : Animal<Any?> = Dog() // error at the constructor call

[Joffrey]

By default, generics are invariant, which means there is no subtyping relations between different Animal<T> types even if there is a subtype relation between the T inside. So what you're seeing is expected.

If you want Animal<Int> to be a subtype of Animal<Any?> , you need to make Animal<T> covariant in T. This is done by adding the keyword out in front of T

[poohbar]

open class Animal<out T>
class Dog: Animal<Int>()
val x : Animal<Any?> = Dog() // works

[poohbar]

i think i get it.. it is restrictive in some cases where i want to just “escape” Kotlin’s type system and go fully dynamic.. something like using List in Java. I don’t think it’s possible in Kotlin 🤔

[Jacob]

What does an animal do with Ts? Do they have a method that returns them? then it makes sense that a dog is an animal<any> since it returns Ints which are techincally also Anys

Do animals eat Ts? (ie have functions that take T as an arg) Than a dog is not an animal <any> since it doesn't eat anything, dogs only eat ints

[Jacob]

You can go fully Dynamic just like java!

open class Animal
class Dog: Animal()
val x : Animal = Dog() // works

😆

[poohbar]

i know i know.. in most cases the generics are very helpful which is why i dont want to just remove them

[Joffrey]

Kotlin doesn't have Java's raw types (which are pretty bad) but maybe you are looking for the syntax Animal<*>

[ephemient]

List<out E> is how it's declared in Kotlin, because an unmodifiable list is covariant. Java's List<E> is mutable thus the only reasonable behavior for the generic is invariant. (Kotlin does the same with MutableList<E>.) Java treats arrays as covariant for historical reasons, but that's very broken (see https://docs.oracle.com/javase/8/docs/api/java/lang/ArrayStoreException.html)

[Vampire]

Java also just allows raw types for backwards compatibility.
Any code that uses them intentionally should be considered broken and wrong.

[Joffrey]

Any code that uses them intentionally should be considered broken and wrong

We should make a poster or T-shirt out of this 😄

You should see some of the code I found in my previous company... full of raw types, and generics were used in ways that were just here to fool the compiler to make it "at least compile"

[Vampire]

Most codebases probably have those 😄
Doesn't make it better though 🙈

[Jacob]

On the topic of fooling the compiler, take a look at how mockito-kotlin can create instances of anything! https://github.com/mockito/mockito-kotlin/blob/37bbae48634d879640a754a1b122db99f0b[…]n/src/main/kotlin/org/mockito/kotlin/internal/CreateInstance.kt

[ephemient]

I'm not sure I'd call Kotlin's star projection a raw type - it doesn't automatically cast into the generic type, and it exposes a <?> signature to Java

[Joffrey]

I don't believe anyone called the Kotlin star-projection a raw type. What are you referring to?

[ephemient]

oh I misread Björn's reply

[Vampire]

Definitely, didn't intend to imply they are similar. 🙂