11B: Q71 – Q72 – Scala type parameterization & variance interview Q&As

Q71. Does Scala have type erasure as in Java?
A71. Yes. Scala parametrized types loose the type information after compilation in the same way as Java does.

Q72a. What are different type parameter modifiers in Scala?
A72a.

Scala type hierarchy

Scala type hierarchy

Cage[T] T is of any type Invariance
Cage[T <: Animal] T is sub type of an Animal upper bound, which means T can be a Lion, Elephant, etc.
Cage[T >: Animal] T is super type of an Animal lower bound, where the compiler infers the lower type of T which can be an AnyRef (i.e java.lang.Object) or Any
Cage[+T] Cage[Lion] is a sub type of Cage[Animal] if Lion is a sub type of Animal Covariance
Cage[-T] Cage[Animal] is a sub type of Cage[Lion] if Lion is a sub type of Animal Contravariance
Cage[T <% Mamal[T]] There is an implicit conversion from T to Mamal[T] View bound

Q72b. What is the difference between a class level type parameter & a method level type parameter?
A72b. If you declare a type parameter both at the class level & and at the method level, these are two separate parameters. If they have different names as in [T] & [S] then they can be used anywhere. If they have the same name as in [T] and [T] then the method level parameter will shadow the class level parameter within the scope of that method’s definition & implementation, but no where else in the class.

Method level type parameter shadows class level type

The type T in method shadows type T in class level. No compile or runt-time error.

Compile error – no shadowing

You can’t add other fruits to a list of Apple other than an Apple.

Runtime error – upper bound

Type S inferred by the compiler to the upper bound of T. T is Apple then S can be Apple or GrannySmith

No error – lower bound

Type S inferred by the compiler to the lower bound of T. if T is Apple then S can be any lower bound as in Apple, Fruit, Object or any as shown below.

Q72c. What is wrong with the below code?

A72c. The MyList[T] is an invariant type, which means when you ask the question

If Apples are Fruits, then is MyList[Apple] also MyList[Fruit], the answer is no for invariant type MyList[T] & yes for the covariant type MyList[+T], hence you get a compile error on the declaration of:

Fix #1: define it with invariant

Fix #2: make the declaration covariant

Q72d. What is wrong with the below code?

A72d. It compiles & run fine. MyList[-T] is contravariant.

If Apples are Fruits, then is MyList[Apple] also MyList[Fruit], the answer is backwards for covariant type MyList[-T]. This means “If Apples are Fruits, then is MyList[Fruit] also MyList[Apple], hence no compile error on line:

You will get a compile error for below:

Q72e. Why does the below code gives a compile error “Covariant type T occurs in contravariant position in type T of value element“? how will you fix it?

A72e. Since the “fruitBasket” is of type “MyList[Fruit]”, it can take any type of fruit, but add(element: T) restricts to only type apple. This can be fixed with add[S >: T](element: S) where the compiler can infer the lower bound.

More on this topic at 11C: Q73 – Q77 – Scala type parameterization & variance interview Q&As.


Don't be overwhelmed by the number of Q&As & tech stacks as nobody knows everything, and often key Q&As at the right moment makes a difference.

500+ Java Interview FAQs

Java & Big Data Tutorials

Top