Typealias — qué es, sintaxis y uso en Kotlin

¿Qué es typealias?

Typealias (alias de tipo) es una declaración que introduce un nombre alternativo para un tipo existente. Sintaxis: typealias NuevoNombre = TipoExistente. Tras la declaración, NuevoNombre se puede usar donde se espera TipoExistente — el compilador los trata como el mismo tipo. A nivel de bytecode, typealias no deja rastro: toda la información del alias se borra en tiempo de compilación.

El propósito principal de typealias es mejorar la legibilidad del código. En lugar de una firma verbosa fun process(callback: (Result) -> Unit), se puede escribir typealias Callback = (Result) -> Unit y usar Callback como tipo de parámetro. Esto es especialmente útil cuando el mismo tipo funcional se repite en varios lugares del código: el alias sirve como punto único de definición y documenta el propósito del tipo.

Typealias no crea un nuevo tipo — es solo un sinónimo. Las variables de tipo Callback y (Result) -> Unit son totalmente intercambiables. El compilador no generará un error si se pasa una lambda directamente a una función que espera Callback. Esto distingue a typealias de inline class (value class), que crea un nuevo tipo envoltorio con comprobación en tiempo de compilación. Typealias es renombrar, no envolver.

Typealias para tipos funcionales

El caso de uso más común de typealias en Kotlin son los tipos funcionales. Las firmas largas como (Int, String) -> Boolean o (List) -> Result dificultan la lectura del código. Typealias las convierte en nombres cortos y significativos que documentan el propósito de la función: typealias Validator = (String) -> Boolean especifica que este es un validador de cadenas.

// Without typealias
fun findUsers(
    filter: (List<User>) -> List<User>
): List<User>

// With typealias
typealias UserFilter = (List<User>) -> List<User>

fun findUsers(filter: UserFilter): List<User>

// Usage in class
typealias OnClickListener = (View) -> Unit

class Button {
    var onClick: OnClickListener = {}
}

En el ejemplo, el typealias UserFilter oculta el tipo funcional complejo (List) -> List detrás de un nombre corto. La firma de findUsers se vuelve legible: "acepta UserFilter, devuelve List". El typealias OnClickListener hace que el código se asemeje a una declaración de interfaz pero sin la sobrecarga de crear una interfaz o clase abstracta separada. Mientras tanto, las lambdas y funciones anónimas siguen funcionando normalmente — typealias no requiere cambios en el código llamante.

Typealias con genéricos

Typealias admite parámetros genéricos, lo que lo hace aún más flexible. Se puede definir typealias Mapper = (T) -> R y usarlo con cualquier tipo. El compilador sustituye tipos específicos por los parámetros en cada uso del alias, preservando la seguridad de tipos completa.

// Generic typealias
typealias Mapper<T, R> = (T) -> R
typealias Provider<T> = () -> T
typealias ListTransformer<T> = (List<T>) -> List<T>

fun processNumbers(mapper: Mapper<Int, String>) {
    // mapper type is (Int) -> String
}

fun main() {
    val config: Provider<String> = { "default config" }
    val reverse: ListTransformer<Int> = { it.reversed() }
}

En el listado, Mapper es un alias genérico para cualquier transformación de T a R. Provider es un proveedor de valor (una fábrica sin argumentos). ListTransformer es una función de transformación de listas. Al llamar a processNumbers(mapper: Mapper), el compilador expande el alias a (Int) -> String. Los genéricos hacen de typealias una herramienta universal adecuada para cualquier contexto sin duplicar declaraciones.

Typealias para nombres anidados y largos

Las clases anidadas y los tipos parametrizados largos son otra área donde typealias simplifica significativamente el código. Si una clase está profunda en una jerarquía de anidamiento (Outer.Inner.Nested), referenciarla por su nombre completo satura el código. Typealias acorta dicho acceso y lo hace más legible. Esto es especialmente relevante para clases de bibliotecas de terceros con nombres largos.

// Alias for nested class
class NetworkResponse {
    class Error(val code: Int, val message: String)
}
typealias NetworkError = NetworkResponse.Error

// Alias for long library type
typealias UserId = Long
typealias JsonMap = Map<String, Any?>

fun process(error: NetworkError) {
    println("${error.code}: ${error.message}")
}

fun parseJson(data: JsonMap): UserId {
    return data["id"] as? Long ?: 0L
}

En el ejemplo, NetworkError es un alias para la clase anidada NetworkResponse.Error. Al importar el typealias, se puede usar NetworkError como un tipo normal sin revelar la jerarquía de anidamiento. JsonMap documenta que el mapa representa un objeto JSON. UserId aclara el propósito de Long en un contexto específico — el lector entiende inmediatamente que se trata de un identificador de usuario, no de un número arbitrario. Sin embargo, typealias no impide pasar un Long simple donde se espera UserId — para eso se necesita una value class.

Typealias vs inline class: diferencias

Typealias e inline class (value class) resuelven problemas diferentes, aunque ambos introducen un nuevo nombre para un tipo. Typealias es solo un sinónimo: una variable de tipo UserId = Long acepta cualquier Long sin comprobación. Inline class envuelve un valor en un nuevo tipo que se comprueba en tiempo de compilación: no se puede pasar un Long simple donde se espera una inline class UserId sin una conversión explícita.

La tabla muestra la diferencia entre los dos mecanismos. Typealias es adecuado para nombres concisos y documentación del código cuando no se requiere tipado estricto. Inline class mediante la palabra clave value class (anteriormente inline class) es necesaria cuando es importante distinguir valores semánticamente diferentes del mismo tipo primitivo. Por ejemplo, UserId y OrderId son ambos Long, pero pasar uno donde se espera el otro es un error lógico que value class previene en tiempo de compilación.