Varianza en la declaración: out e in

La lección anterior terminó con un diagnóstico y sin tratamiento: sabemos que la varianza de un tipo genérico está determinada por las posiciones en que aparece su parámetro, pero seguimos escribiendo tipos invariantes porque no le hemos dicho nada al compilador. Las dos palabras que faltan son out e in, y su colocación revela una decisión de diseño que separa a Kotlin de Java con nitidez. En Java, quien sufre el problema es quien escribe la firma que consume el tipo, y por eso los comodines se repiten en cada parámetro de cada método de cada API. En Kotlin, quien lo resuelve es quien declara el tipo, una vez, y a partir de ahí todos sus usuarios heredan la solución sin escribir nada. El precio de esa comodidad es que el compilador deja de creerte y empieza a comprobarte: en el momento en que escribes out, una lista de construcciones perfectamente normales se vuelve ilegal dentro de tu clase, y entender exactamente cuáles y por qué es el trabajo de esta lección.

out: prometer que el tipo solo sale

Escribir out delante de un parámetro de tipo es una promesa con dos caras. Hacia fuera, declara que el tipo construido conserva la relación de subtipos, de modo que Fuente<Perro> pasa a ser subtipo de Fuente<Animal> y puede entregarse en cualquier sitio donde se espere el segundo. Hacia dentro, se convierte en una obligación que el compilador verifica línea a línea: el parámetro solo puede aparecer en posiciones de salida.

interface Fuente<out T> {
    fun siguiente(): T
    val ultimo: T
    fun tresPrimeros(): List<T>
    // fun aceptar(valor: T)      // prohibido: T en posicion de entrada
    // var actual: T              // prohibido: un var tambien escribe
}

open class Animal
class Perro : Animal()

val perros: Fuente<Perro> = TODO()
val animales: Fuente<Animal> = perros    // valido gracias a out

La prohibición sobre var es la que más desconcierta, y es también la más instructiva. Una propiedad de solo lectura tiene un único accesor que devuelve T, luego es pura salida; una propiedad mutable tiene además un setter que recibe un T, y ese parámetro oculto basta para romper la promesa. La regla no habla de sintaxis sino de la firma real que se genera, y por eso val es aceptable y var no lo es aunque a simple vista sean la misma línea con una letra distinta.

Hay una consecuencia elegante que aparece en cuanto se acepta la covarianza. Como Nothing es subtipo de absolutamente todos los tipos, una List<Nothing> resulta ser subtipo de cualquier List<T> imaginable, y por eso la biblioteca estándar puede tener una única instancia compartida para la lista vacía en lugar de crear una por cada tipo de elemento. No es un truco de implementación: es la varianza haciendo su trabajo en el sitio más extremo posible del retículo de tipos.

in: prometer que el tipo solo entra

La anotación simétrica invierte todo lo anterior. Un parámetro marcado con in invierte la relación de subtipos, de modo que un Sumidero<Animal> es subtipo de Sumidero<Perro> y sirve allí donde se pida el segundo. A cambio, el parámetro solo puede aparecer en posiciones de entrada, y por tanto no puede ser el tipo de retorno de ningún método público ni el tipo de ninguna propiedad.

interface Sumidero<in T> {
    fun aceptar(valor: T)
    fun aceptarTodos(valores: List<T>)
    fun descartar(): Nothing = throw UnsupportedOperationException()
    // fun ultimo(): T           // prohibido: T en posicion de salida
}

val deAnimales: Sumidero<Animal> = TODO()
val dePerros: Sumidero<Perro> = deAnimales   // valido gracias a in

El ejemplo canónico de la biblioteca estándar es Comparable, declarada como Comparable<in T> porque su único método recibe el otro operando y devuelve un entero. Gracias a esa anotación, una implementación capaz de comparar cualquier Number puede usarse donde se exija comparar Int, sin que nadie tenga que escribir un adaptador. La misma lógica gobierna Comparator, los canales de solo envío de las corrutinas y cualquier interfaz de retrollamada que reciba un evento y no devuelva nada.

// En la biblioteca estandar: interface Comparable<in T>

val comparadorGeneral: Comparator<Animal> = Comparator { _, _ -> 0 }
val paraPerros: Comparator<Perro> = comparadorGeneral   // valido gracias a in

fun ordenar(perros: List<Perro>, criterio: Comparator<in Perro>) =
    perros.sortedWith(criterio)

La última firma anticipa la lección siguiente: cuando el tipo ya viene anotado, la mayoría de los usos no necesitan escribir nada, pero un parámetro declarado con una restricción explícita permite documentar en la propia firma que se admite cualquier comparador más general. Es la misma idea vista desde el otro extremo del contrato.

Que un método pueda devolver Nothing en una interfaz contravariante no es una excepción a la regla sino una aplicación suya: Nothing es subtipo de todo, así que aparece con seguridad en cualquier posición de salida por restrictiva que sea.

Las tres excepciones y lo que revelan

La comprobación del compilador tiene exactamente tres huecos, y cada uno tiene una justificación distinta que conviene no confundir.

El primero son los parámetros del constructor. Un constructor no es un método al que se pueda llamar sobre un objeto ya existente a través de una referencia de supertipo, de modo que no hay ninguna forma de aprovecharlo para colar un valor del tipo equivocado. Por eso una clase covariante puede recibir su parámetro de tipo en el constructor sin problema alguno.

class Caja<out T>(val contenido: T)          // valido: el parametro es del constructor
class Par<out A, out B>(val primero: A, val segundo: B)

val cajaDePerro: Caja<Perro> = Caja(Perro())
val cajaDeAnimal: Caja<Animal> = cajaDePerro

El segundo son los miembros privados. La varianza es una propiedad del contrato público, porque solo a través del contrato público puede alguien ver el objeto con un tipo estático distinto del real. Un método privado no forma parte de ese contrato, y por tanto puede usar el parámetro en cualquier posición sin poner nada en riesgo.

class Almacen<out T>(private val elementos: MutableList<@UnsafeVariance T>) {
    fun leer(indice: Int): T = elementos[indice]
    private fun anotar(valor: T) { elementos.add(valor) }   // privado: permitido
}

El tercero es la anotación de escape que aparece en la línea anterior, y es la más delicada. Existe porque a veces una operación menciona el parámetro en una posición prohibida sin llegar a comprometer nada. El caso canónico está en la propia biblioteca estándar: List<out E> declara contains con un parámetro de tipo E, lo que sobre el papel es una posición de entrada, pero la implementación se limita a comparar por igualdad y nunca almacena el valor recibido. La anotación le dice al compilador que deje de comprobar ahí, y es responsabilidad de quien la escribe que la promesa siga siendo cierta.

flowchart TD
A[Donde aparece el parametro de tipo] --> B{Posicion}
B -- Tipo de retorno o val --> S[Posicion de salida]
B -- Parametro de metodo o setter --> E[Posicion de entrada]
S --> OK1[Compatible con out]
E --> OK2[Compatible con in]
S --> KO2[Incompatible con in]
E --> KO1[Incompatible con out]
A --> X{Es constructor o miembro privado}
X -- Si --> LIBRE[Sin comprobacion de varianza]

Por qué en la declaración y no en el uso

Java resolvió el mismo problema en el lugar opuesto. Como sus tipos genéricos son siempre invariantes, la flexibilidad se consigue escribiendo comodines en cada firma que quiera aceptar más de un argumento de tipo, con la fórmula que la comunidad memorizó como productor extiende y consumidor supera. El resultado funciona, pero desplaza el coste a quien menos información tiene.

// Java: la varianza se escribe una vez por cada uso
static void volcar(List<? extends Animal> origen, List<? super Perro> destino) {
    for (Animal a : origen) { /* ... */ }
}

Kotlin observó que en la inmensa mayoría de los casos el autor del tipo ya sabe si su clase produce o consume, y que obligar a repetir esa información en cada firma de cada cliente es redundante y propenso al olvido. Al anotar List<out E> una sola vez, todas las funciones que reciban una List obtienen la flexibilidad gratis y ningún autor de API tiene que acordarse de nada. La contrapartida es que la varianza en la declaración solo es aplicable cuando el tipo es realmente puro en un sentido, y hay tipos que no lo son: MutableList produce y consume, y ninguna anotación va a arreglarlo. Para esos casos Kotlin conserva también el mecanismo del punto de uso, que es el asunto de la lección siguiente. Los dos mecanismos no compiten, se reparten el terreno: la declaración cubre los tipos que tienen una vocación clara, y el uso rescata a los que no la tienen.