Item 23: Avoid shadowing type parameters

It is possible to define property and parameters with the same name due to shadowing. Local parameter shadows outer scope property. There is no warning because such a situation is not uncommon and is rather visible for developers:

  1. class Forest(val name: String) {
  3.    fun addTree(name: String) {
  4.        // ...
  5.    }
  6. }

On the other hand, the same can happen when we shadow class type parameter with a function type parameter. Such a situation is less visible and can lead to serious problems. This mistake is often done by developers not understanding well how generics work. 

  1. interface Tree
  2. class Birch: Tree
  3. class Spruce: Tree
  5. class Forest<T: Tree> {
  7.    fun <T: Tree> addTree(tree: T) {
  8.        // ...
  9.    }
  10. }

The problem is that now Forest and addTree type parameters are independent of each other:

  1. val forest = Forest<Birch>()
  2. forest.addTree(Birch())
  3. forest.addTree(Spruce())

Such situation is rarely desired and might be confusing. One solution is that addTree should use the class type parameter T:

  1. class Forest<T: Tree> {
  3.    fun addTree(tree: T) {
  4.        // ...
  5.    }
  6. }
  8. // Usage
  9. val forest = Forest<Birch>()
  10. forest.addTree(Birch())
  11. forest.addTree(Spruce()) // ERROR, type mismatch

If we need to introduce a new type parameter, it is better to name it differently. Note that it can be constrained to be a subtype of the other type parameter:

  1. class Forest<T: Tree> {
  3.    fun <ST: T> addTree(tree: ST) {
  4.        // ...
  5.    }
  6. }

Summary

Avoid shadowing type parameters, and be careful when you see that type parameter is shadowed. Unlike for other kinds of parameters, it is not intuitive and might be highly confusing.