Cómo se decide una característica: leer el proceso KEEP como se lee una constitución

La documentación de un lenguaje te dice qué hace. El proceso de evolución te dice por qué hace eso y no otra cosa, qué se descartó por el camino y qué precio se pagó por lo que quedó. En Kotlin ese proceso tiene nombre, repositorio público y un archivo entero de propuestas: el KEEP, siglas de Kotlin Evolution and Enhancement Process. Leerlo cambia la relación con el lenguaje, porque deja de parecer un conjunto de decisiones tomadas por alguien en otra parte y se convierte en un registro de compromisos discutidos, muchos de ellos difíciles, casi todos con las objeciones escritas al lado. Quien quiera opinar seriamente sobre Kotlin —o, más modestamente, entender por qué le falta algo que en otro lenguaje tiene— tiene que aprender a leer ese registro.

Qué es exactamente una propuesta y qué contiene

Una propuesta KEEP es un documento en texto plano que vive en un repositorio público y que, en su forma madura, contiene siempre las mismas partes: una motivación que describe el problema en términos de código real que hoy se escribe mal, una propuesta de sintaxis y semántica, una sección de casos de uso, una discusión explícita de alternativas consideradas —esta es la parte que más se aprende leyendo—, un apartado sobre compatibilidad hacia atrás y otro sobre el impacto en las herramientas y en el código ya escrito. Esa estructura no es decorativa. Cada apartado corresponde a una objeción que históricamente ha hundido propuestas, de modo que el formulario es, en realidad, una lista de comprobación de las formas conocidas de equivocarse al diseñar un lenguaje. Alrededor del documento vive la discusión: un hilo público donde se plantean objeciones, y un rastro de incidencias en YouTrack donde se registran los problemas concretos que van apareciendo durante la implementación.

Hay una segunda vía de entrada que conviene conocer porque es la que usa casi todo el mundo sin saberlo. Antes de que exista una propuesta suele existir una incidencia en el sistema de seguimiento, abierta por alguien que tropezó con una limitación concreta escribiendo código normal. Esas incidencias se acumulan, se enlazan entre sí y en algún momento alguien observa que veinte de ellas son la misma pregunta formulada de veinte maneras. Ese es el instante en que nace una propuesta, y por eso el mejor servicio que puede prestar alguien que programa a diario no es proponer sintaxis sino reportar bien el problema: qué querías escribir, qué tuviste que escribir en su lugar y qué se rompió al hacerlo.

Lo que distingue a este proceso de un simple buzón de sugerencias es que la carga de la prueba está invertida. Una propuesta no tiene que demostrar que sería útil, cosa que casi cualquier característica puede demostrar; tiene que demostrar que su utilidad supera el coste permanente de existir. Ese coste incluye la complejidad añadida al modelo mental de todos los usuarios presentes y futuros, la interacción con cada característica ya existente, el trabajo de mantenimiento en cuatro backends, la carga sobre las herramientas y, sobre todo, el cierre de puertas: cada sintaxis que se ocupa es una sintaxis que ya no está disponible para nada mejor que pueda venir después.

Ese último punto merece subrayarse porque es el menos intuitivo. La gramática de un lenguaje es un recurso finito: hay un número limitado de símbolos, de posiciones y de formas que resultan legibles, y gastarlos en algo mediocre tiene un coste que solo se descubre años después, cuando aparece una idea mejor que habría encajado justo ahí y ya no cabe. Buena parte de las discusiones que parecen puramente estéticas en una propuesta —qué símbolo usar, si va antes o después, si necesita palabra clave— son en realidad discusiones sobre presupuesto.

flowchart LR
IDEA[Idea o incidencia en YouTrack] --> PROP[Propuesta KEEP publicada]
PROP --> DISC[Discusion publica y revision del diseno]
DISC --> PROTO[Prototipo tras una bandera del compilador]
PROTO --> EXP[Experimental con adhesion explicita]
EXP --> PREV[Previsualizacion en una version del lenguaje]
PREV --> EST[Estable con garantia de compatibilidad]
DISC --> RECH[Rechazada o aplazada con motivos escritos]
PROTO --> RECH

Conviene fijarse en que hay dos flechas que llegan al rechazo y en que una de ellas sale del prototipo. Eso significa que una propuesta puede morir después de estar implementada y funcionando, cosa que en la mayoría de los proyectos resultaría impensable porque el esfuerzo invertido se convierte en un argumento a favor de conservarlo. Aquí el esfuerzo invertido no cuenta como argumento, y esa disciplina es lo que impide que el lenguaje acumule características que nadie defendería si hubiera que proponerlas hoy desde cero.

El camino de experimental a estable, y qué garantiza cada escalón

Kotlin no publica características terminadas de golpe. Las hace pasar por escalones con garantías crecientes, y entender esos escalones es lo que separa a un equipo que adopta novedades con criterio de uno que se lleva sustos. En el nivel más bajo, una característica vive detrás de una bandera del compilador y puede cambiar de sintaxis entre versiones menores sin previo aviso. Después pasa a un estado experimental en el que ya existe públicamente pero exige adhesión explícita: quien la use está firmando que acepta el riesgo, y esa firma es visible en el código y auditable en una revisión.

// Adhesion explicita: el uso queda marcado en el codigo, no escondido.
@OptIn(ExperimentalStdlibApi::class)
fun analizar(datos: ByteArray): String = datos.toHexString()

// Marcar una API propia como experimental: mismo mecanismo, tu propio marcador.
@RequiresOptIn(message = "API interna en evaluacion", level = RequiresOptIn.Level.ERROR)
annotation class ApiEnEvaluacion

Ese mecanismo de adhesión explícita no es solo para la biblioteca estándar: está pensado para que cualquiera lo use en su propio código, y es una de las herramientas de diseño más infrautilizadas del lenguaje. Un equipo que publica un módulo interno puede marcar la parte todavía en evaluación con su propio marcador y obtener exactamente la misma propiedad que obtiene el equipo de Kotlin: que el uso de algo inestable sea visible en el punto de uso, contable con una búsqueda y discutible en una revisión, en lugar de invisible hasta el día de la migración.

El escalón siguiente es la previsualización asociada a una versión del lenguaje, que permite compilar el código de mañana con el compilador de hoy para probarlo de verdad en proyectos reales antes de que las garantías se congelen. Y por encima está la estabilidad, que en Kotlin significa algo muy concreto y muy caro de sostener: compatibilidad de fuente y compatibilidad binaria dentro de la misma rama, y la promesa de que si algo tiene que romperse se romperá con un ciclo de deprecación que empieza en aviso, sigue en error y termina en ocultación, con varias versiones de margen y con migraciones automáticas siempre que sea posible. Cuando un cambio afecta a las garantías del lenguaje, no lo decide solo el equipo que lo implementa: existe un comité de lenguaje dentro de la fundación cuya función es justamente proteger a quienes ya escribieron código.

Un caso real de principio a fin: de receptores a parámetros de contexto

El mejor ejercicio para entender el proceso es seguir una característica que no salió bien a la primera. Los receptores de contexto se propusieron para resolver un problema viejo y muy concreto: hay funciones que solo tienen sentido cuando están disponibles ciertas capacidades del entorno —un registrador, una transacción, un ámbito de corrutina, un formateador— y hasta entonces esas capacidades había que pasarlas como parámetro en cada llamada, ensuciando cada firma, o esconderlas en estado global, perdiendo trazabilidad. La primera propuesta permitía que una función declarase varios receptores implícitos a la vez.

El prototipo se publicó, la comunidad lo usó, y con el uso aparecieron los problemas: la resolución se volvía difícil de predecir cuando varios receptores ofrecían miembros con el mismo nombre, el código resultante era difícil de leer para quien llegaba nuevo porque no había forma de saber de dónde venía cada símbolo, y la interacción con las funciones de extensión producía casos que ni siquiera los autores sabían explicar rápido. En lugar de estabilizar lo que ya funcionaba a medias, la propuesta se retiró y se rediseñó: los contextos pasaron a ser parámetros con nombre en lugar de receptores anónimos, lo que devuelve la legibilidad y hace la resolución explicable, a cambio de un poco más de ceremonia. Esa segunda versión es la que se estabilizó en la versión 2.4 publicada en junio de 2026.

// Un contexto con nombre: se sabe de donde viene cada capacidad.
context(registro: Registrador)
fun transferir(origen: Cuenta, destino: Cuenta, importe: Dinero) {
    registro.info("transferencia iniciada")
    origen.retirar(importe)
    destino.ingresar(importe)
}

// El llamante aporta el contexto una vez, no en cada firma intermedia.
with(RegistradorConsola()) {
    transferir(a, b, Dinero(100))
}

Compárese con las dos alternativas que el diseño desplaza. La primera es pasar la capacidad como parámetro ordinario, que funciona y es explícita, pero contamina cada firma de la cadena de llamadas incluida la de las funciones intermedias que no usan la capacidad para nada y solo la transportan. La segunda es un estado global accesible desde cualquier sitio, que no contamina ninguna firma y a cambio destruye la trazabilidad y hace que las pruebas necesiten coordinación. Los parámetros de contexto ocupan exactamente el hueco entre ambas: la capacidad se declara donde se usa, se aporta donde se sabe y no aparece en medio.

La lección no es que el diseño original fuera malo, sino que el proceso tenía un mecanismo para descubrir que lo era antes de que fuera irreversible, y la voluntad de usarlo. Un lenguaje que estabiliza todo lo que prototipa acumula deuda para siempre; uno que retira propuestas maduras acepta pagar años de trabajo a cambio de no cargar a millones de personas con una decisión mediocre.

Hay un segundo aprendizaje escondido en este caso y es sobre el orden de las preguntas. La discusión no giró en ningún momento sobre si la característica era útil, cosa que estaba clara desde el primer día porque el problema era real y todo el mundo lo había sufrido. Giró sobre si la forma propuesta era explicable: si alguien que abre un fichero por primera vez puede saber de dónde viene cada símbolo sin ejecutar mentalmente el algoritmo de resolución. Cuando la respuesta resultó ser que no, ninguna cantidad de utilidad compensó, y la solución fue exactamente la que devuelve la explicabilidad al precio de escribir un nombre.

// La deprecacion como contrato, con la migracion incluida en la anotacion.
@Deprecated(
    message = "Usa transferir con el nuevo parametro de contexto",
    replaceWith = ReplaceWith("transferir(origen, destino, importe)"),
    level = DeprecationLevel.WARNING
)
fun transferirAntiguo(origen: Cuenta, destino: Cuenta, importe: Dinero) { }

Por qué Kotlin dice que no a cosas que parecen obvias

La lista se puede alargar y todas las entradas cuentan la misma historia. No hay una palabra reservada para los miembros estáticos porque los objetos acompañantes cubren el caso con un mecanismo que además es un objeto de verdad, capaz de implementar interfaces y de recibir extensiones. No hay una visibilidad equivalente a la de paquete de Java porque los paquetes de Kotlin no son unidades de encapsulación y añadirla habría exigido cambiar qué significa un paquete. No hay macros porque la generación de código mediante procesadores resuelve la mayoría de los casos con un modelo mucho más simple de depurar, y porque un sistema de macros convierte cada base de código en un dialecto. En todos los casos el rechazo viene acompañado de una alternativa que ya existe, y esa es la señal de que la decisión estaba tomada desde el diseño y no desde la falta de tiempo.

Hay un patrón común en casi todos los rechazos, y conviene enunciarlo porque es transferible al diseño de cualquier API propia: Kotlin protege sistemáticamente la capacidad de leer código ajeno por encima de la comodidad de escribir código propio. Cada vez que una propuesta hace más rápido escribir a costa de hacer más difícil saber qué hace un fragmento sin abrir otros ficheros, la propuesta pierde. Ese sesgo explica el rechazo de los implícitos no marcados, explica que las extensiones se resuelvan estáticamente en lugar de participar en el despacho dinámico, explica que la herencia esté cerrada por defecto y explica que la nulabilidad tenga que declararse.

El sesgo tiene un límite y también conviene nombrarlo, porque de lo contrario se convierte en una excusa para no añadir nada nunca. Kotlin sí acepta pagar complejidad cuando la característica elimina una clase entera de errores o cuando desbloquea algo que no se podía expresar de ninguna forma razonable. La nulabilidad en el tipo es cara de aprender y se aceptó. Las corrutinas añadieron un modelo mental completo y se aceptaron. Los genéricos con varianza declarada son de las partes más difíciles del lenguaje y están ahí. El criterio, entonces, no es la simplicidad a toda costa sino una relación: cuánta complejidad se añade al modelo mental de todos frente a cuántos errores se vuelven imposibles para todos.