Parámetros de tipo y restricciones

La primera vez que se escribe un genérico casi siempre se escribe por imitación: alguien vio List<String> en una firma ajena y dedujo que las puntas de flecha eran una especie de adorno obligatorio para las colecciones. Esa lectura sobrevive durante años sin causar daño visible, hasta el día en que el compilador rechaza una línea con un mensaje sobre información insuficiente para inferir una variable de tipo y no hay nada en la intuición acumulada que sirva para responder. El desbloqueo consiste en aceptar una idea sencilla y de consecuencias enormes: un parámetro de tipo es literalmente un parámetro. Tiene un nombre, tiene un ámbito donde ese nombre significa algo, admite restricciones sobre los valores que puede recibir y se le pasa un argumento en cada llamada, aunque casi siempre lo pase el compilador por ti. Todo lo demás en este nivel, incluida la varianza, es consecuencia de tomarse esa frase en serio.

El parámetro de tipo y su ámbito

Una función corriente abstrae sobre valores: en lugar de escribir el número tres dentro del cuerpo, se declara un parámetro y se recibe cualquier número. Un parámetro de tipo hace exactamente lo mismo un nivel más arriba: en lugar de fijar String en la firma, se declara un nombre y se recibe cualquier tipo. La única diferencia es que la sustitución no ocurre durante la ejecución sino durante la compilación, y por eso el argumento se escribe entre puntas de flecha en vez de entre paréntesis.

La posición de la declaración cambia según lo que se esté declarando, y esa asimetría desconcierta al principio. En una función, el bloque <T> va antes del nombre, porque el nombre ya pertenece a la firma que va a usar T. En una clase, va después, porque el nombre de la clase es lo que se está parametrizando. En una extensión conviven ambas reglas: la declaración precede al tipo receptor, que a su vez ya puede mencionar el parámetro.

fun <T> primeroOPorDefecto(lista: List<T>, alternativa: T): T =
    lista.firstOrNull() ?: alternativa

class Caja<T>(private var contenido: T) {
    fun leer(): T = contenido
    fun escribir(valor: T) { contenido = valor }
}

fun <T> Caja<T>.duplicar(): Pair<T, T> = leer() to leer()

El ámbito es la parte que se suele pasar por alto y la que produce los errores más opacos. Un parámetro declarado en la clase es visible en toda la clase: en las firmas de sus métodos, en los tipos de sus propiedades y en el cuerpo de unas y otras. Un parámetro declarado en una función solo es visible en esa función. La consecuencia incómoda aparece en el objeto acompañante, que pertenece a la clase pero no a ninguna instancia suya: como no hay instancia, no hay argumento de tipo, y el parámetro de la clase simplemente no existe allí dentro.

class Registro<T>(val elementos: List<T>) {
    companion object {
        // fun vacio(): Registro<T> = Registro(emptyList())  // error: T no existe aqui
        fun <T> vacio(): Registro<T> = Registro(emptyList()) // este T es OTRO parametro
    }
}

Que el segundo T sea un parámetro distinto que casualmente comparte nombre no es un tecnicismo: es la misma regla de sombreado que gobierna las variables locales, aplicada al mundo de los tipos.

Restricciones: el límite superior implícito y el explícito

Cuando se escribe <T> sin más, Kotlin no está diciendo que T pueda ser cualquier cosa arbitraria: está aplicando un límite superior implícito, y ese límite es Any?. La consecuencia práctica es inmediata y sorprende a casi todo el mundo la primera vez: T puede ser un tipo nulable, y por tanto dentro de la función no se puede llamar a ningún miembro sobre un valor de tipo T sin comprobación previa.

fun <T> describir(valor: T): String = valor.toString()   // valor puede ser nulo
fun <T : Any> describirNoNulo(valor: T): String = valor.toString()

describir(null)          // compila: T se infiere como Nothing?
// describirNoNulo(null) // no compila: el limite prohibe la nulabilidad

Escribir T : Any es, entonces, la forma canónica de exigir no nulabilidad, y no una redundancia. A partir de ahí, cualquier tipo puede servir de límite, y el ejercicio interesante es el límite recursivo, en el que el parámetro aparece dentro de su propia restricción. La firma <T : Comparable<T>> dice que T debe saber compararse consigo mismo y no con otra cosa, lo que impide comparar una fecha con un entero aunque ambos sean comparables por separado. Esta construcción tiene nombre propio en la literatura de sistemas de tipos, polimorfismo acotado por F, y es la única forma de expresar en una firma la idea de que un tipo se relaciona con su propia identidad.

fun <T : Comparable<T>> maximo(a: T, b: T): T = if (a > b) a else b

maximo(3, 9)                  // Int es Comparable<Int>
maximo("alfa", "beta")        // String es Comparable<String>
// maximo(3, "beta")          // no hay ningun T que satisfaga ambas cosas

Varias restricciones con where

Entre las puntas de flecha solo cabe un límite. En cuanto un parámetro deba cumplir dos condiciones a la vez, la sintaxis se traslada a una cláusula where situada después de la firma y antes del cuerpo. La regla estructural es la misma que en la herencia: de todos los límites, como mucho uno puede ser una clase, y el resto han de ser interfaces.

fun <T> volcarOrdenado(origen: Iterable<T>, destino: MutableList<String>)
    where T : CharSequence,
          T : Comparable<T> {
    origen.sorted().forEach { destino.add(it.toString()) }
}

class IndicePorClave<K, V>(private val extraer: (V) -> K)
    where K : Comparable<K>,
          V : Any

La cláusula sirve igualmente para clases e interfaces, y cuando hay varios parámetros de tipo permite restringir cada uno por separado sin que la firma se vuelva ilegible. Ese es su verdadero mérito: no añade poder expresivo respecto de escribir un límite en la posición corta, lo añade respecto de acumular límites, que en la posición corta es imposible.

flowchart TD
A[Necesito restringir un parametro de tipo] --> B{Cuantas condiciones}
B -- Una --> C[Escribela en las puntas de flecha]
B -- Varias --> D[Usa la clausula where]
D --> E{Alguna es una clase}
E -- Como mucho una --> F[Valido]
E -- Dos o mas --> G[Error: solo una clase, el resto interfaces]

De dónde salen los argumentos de tipo

Casi nunca se escriben, y por eso conviene saber exactamente de dónde vienen. El compilador dispone de tres fuentes y las consulta en conjunto, no en cascada. La primera son los tipos de los argumentos de la llamada: si a primeroOPorDefecto se le pasa una List<Int>, la ecuación se resuelve sola. La segunda es el tipo esperado en el punto donde se usa la expresión, que puede ser la anotación de una variable, el tipo de retorno de la función que la envuelve o el tipo del parámetro al que se pasa. La tercera es la escritura explícita, que sigue estando disponible y no es una derrota.

val a = primeroOPorDefecto(listOf(1, 2, 3), 0)   // T = Int, por los argumentos
val b: List<String> = emptyList()                // T = String, por el tipo esperado
val c = emptyList<String>()                      // T = String, escrito a mano
// val d = emptyList()                           // error: ninguna fuente aporta nada

Cuando los argumentos no coinciden en tipo, la inferencia no falla: busca el supertipo común más específico y lo usa. Ese comportamiento es cómodo y a la vez es el origen de firmas más laxas de lo que uno cree haber escrito, porque un listOf(1, "a") produce silenciosamente una List<Any> y a partir de ahí ninguna operación aritmética vuelve a estar disponible.

val mezcla = listOf(1, "a")            // List<Any>
val numeros = listOf<Number>(1, 2.5)   // List<Number>, fijado a mano
val vacia = mutableListOf<String>()    // sin argumentos no hay nada que inferir