Language modes: romper sin partir el ecosistema

Todo lenguaje longevo se enfrenta a la misma trampa: las decisiones que hoy sabe equivocadas solo pueden corregirse rompiendo código que alguien ya escribió, y romperlo a la vez para todos es la forma más fiable de partir una comunidad en dos. Otros lenguajes han pagado ese precio con divisiones que duraron una década. Swift eligió otra salida, y es probablemente su aportación más original a la ingeniería de lenguajes: hizo del cambio incompatible una unidad discreta, nombrada, activable módulo a módulo y verificable por el propio programa. El resultado es que en un mismo binario conviven módulos compilados bajo reglas distintas, que una migración puede durar meses sin bloquear a nadie y que una funcionalidad puede probarse en producción antes de existir oficialmente.

El problema de romper sin partir

Un cambio incompatible tiene dos costes distintos que conviene no confundir. El primero es el trabajo de migrar, que es finito y en general mecánico. El segundo es el bloqueo: si adoptar la versión nueva exige migrarlo todo a la vez, cualquier dependencia que no haya migrado detiene a todos sus dependientes, y esa cadena se propaga hasta que el ecosistema se congela en la versión antigua.

La solución clásica —una versión mayor que rompe y una migración global— falla precisamente por ese segundo coste. Swift la usó una vez, en la versión 3, cuando todavía podía permitírselo, y decidió no volver a hacerlo. El mecanismo que puso en su lugar descansa en tres piezas que se combinan: las funcionalidades incompatibles se nombran una a una, se pueden activar de forma independiente, y el modo de lenguaje es una propiedad del módulo y no del programa.

Las tres son necesarias. Nombrarlas permite hablar de un cambio concreto en lugar de una versión entera. Activarlas por separado convierte una migración monolítica en una secuencia de trabajos pequeños y verificables. Y que el modo sea del módulo rompe la cadena de bloqueo: una biblioteca compilada con reglas antiguas se importa sin problema desde un módulo compilado con las nuevas.

Conviene separar con cuidado tres cosas que se confunden a diario. La versión del compilador es la herramienta que tienes instalada y avanza sola. El modo de lenguaje es el conjunto de reglas bajo las que se compila un módulo concreto y lo eliges tú. Y la versión mínima de sistema es lo que exigen ciertas funcionalidades que dependen de bibliotecas distribuidas con el sistema operativo. Un compilador nuevo en modo antiguo es la combinación normal durante una migración larga; un compilador nuevo con una funcionalidad que exige un sistema reciente es un problema de despliegue distinto que ninguna bandera resuelve.

Banderas de funcionalidad futura

Una funcionalidad futura es un cambio ya aprobado por el proceso de evolución que rompe compatibilidad de fuente, y que por eso no se activa hasta el siguiente modo de lenguaje. Cada una tiene un identificador propio y puede habilitarse antes con una bandera del compilador.

// Package.swift
.target(
    name: "Dominio",
    swiftSettings: [
        .enableUpcomingFeature("ExistentialAny"),
        .enableUpcomingFeature("InternalImportsByDefault"),
        .swiftLanguageMode(.v5)
    ]
)

Desde la línea de órdenes es -enable-upcoming-feature seguido del identificador. El detalle que importa: activar una bandera nunca es un salto al vacío, porque la funcionalidad ya pasó revisión y su comportamiento está especificado. Lo único que adelantas es el momento en que su incompatibilidad te afecta.

Cuando llega el modo de lenguaje que las incluye, esas banderas quedan activadas por defecto y la opción se vuelve inocua en lugar de errónea. Eso permite mantener un paquete que compile con varias versiones del compilador sin condicionales por todas partes: las banderas de funcionalidades que aún no existen se ignoran con un aviso, no con un error.

La estrategia práctica que se ha impuesto es tratar cada bandera como una tarea independiente. Activas una, resuelves los avisos que provoca, integras el cambio y pasas a la siguiente. Cada paso es pequeño, revisable y reversible, y el estado del proyecto es siempre coherente.

flowchart LR
A[Idea en revision] -->|bandera experimental| B[Se puede probar en snapshots]
B --> C[Propuesta aceptada]
C -->|bandera de funcionalidad futura| D[Adopcion voluntaria por modulo]
D --> E[Siguiente modo de lenguaje]
E --> F[Activada por defecto para todos]
style A fill:#f9e2af,color:#11111b
style D fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b

Modos de lenguaje

El modo de lenguaje es la reunión de todas las funcionalidades incompatibles vigentes en un momento dado. Un mismo compilador entiende varios modos, y esa es la clave del asunto: no necesitas un compilador antiguo para compilar código antiguo, sino el compilador nuevo puesto en modo antiguo. Así el código que no ha migrado sigue recibiendo mejoras de rendimiento, correcciones y diagnósticos mejores mientras conserva las reglas bajo las que se escribió.

// Un modulo migrado y otro que todavia no lo esta,
// en el mismo paquete y en el mismo binario final
.target(name: "Nucleo", swiftSettings: [.swiftLanguageMode(.v6)]),
.target(name: "Heredado", swiftSettings: [.swiftLanguageMode(.v5)])

El modo del que más se habla es el de Swift 6, porque su cambio principal —la comprobación estricta de la concurrencia, que convierte en errores lo que antes eran avisos— es el más exigente que ha introducido el lenguaje. Y precisamente por eso el mecanismo tuvo que existir antes: sin adopción gradual, ese cambio habría dejado fuera a una parte enorme del ecosistema durante años.

Al cruzar la frontera entre modos hay una asimetría que conviene tener presente. Un módulo estricto que importa uno permisivo no puede confiar en las garantías del otro, así que el compilador reduce el rigor de sus comprobaciones sobre lo importado. La migración solo es real de dentro hacia fuera: mientras tus dependencias no adopten el modo, tu módulo lo tiene activado pero no está verificado del todo. Vale la pena saberlo para no confundir una compilación limpia con una garantía completa.

Las versiones recientes añaden además ajustes que no son exactamente funcionalidades sino políticas por defecto, como fijar el aislamiento predeterminado de un módulo al actor principal. Se configuran del mismo modo y merecen la misma disciplina: uno cada vez, con su revisión.

// Politica por defecto en lugar de anotacion repetida
.target(
    name: "Interfaz",
    swiftSettings: [
        .swiftLanguageMode(.v6),
        .defaultIsolation(MainActor.self)
    ]
)
// Con esto el modulo entero vive en el actor principal salvo
// lo que marques explicitamente como no aislado, que es justo
// el reparto que quiere una capa de presentacion.

El gestor de paquetes ha ido incorporando además herramientas de migración asistida que aplican automáticamente los cambios mecánicos que exige activar una funcionalidad concreta. No sustituyen al criterio —los cambios interesantes siguen siendo manuales— pero eliminan la parte tediosa, que en un proyecto grande es la mayoría del trabajo y la fuente principal de errores por fatiga.

Lo experimental

Por debajo de todo lo anterior hay un tercer nivel, y es el que permite participar de verdad en la evolución del lenguaje. Las funcionalidades en discusión —no aprobadas, a veces ni siquiera propuestas formalmente— se implementan tras una bandera experimental y se distribuyen en las instantáneas de desarrollo de la cadena de herramientas.

Activar una es tan sencillo como -enable-experimental-feature con su nombre, pero las condiciones son distintas: exigen normalmente una instantánea de desarrollo, no una versión estable; el diseño puede cambiar entre dos instantáneas consecutivas; y el código escrito contra ellas no debe llegar a producción bajo ninguna circunstancia. Su propósito es otro: permitir que quien va a revisar una propuesta pueda ejecutarla en lugar de imaginarla.

Para escribir código que funcione con y sin la funcionalidad, el lenguaje ofrece directivas de compilación condicional que preguntan por su disponibilidad en lugar de por la versión del compilador.

#if hasFeature(ExistentialAny)
func procesar(_ elementos: [any Identificable]) { }
#else
func procesar(_ elementos: [Identificable]) { }
#endif

#if hasAttribute(retroactive)
extension Fecha: @retroactive Comparable { }
#endif

Preguntar por la funcionalidad y no por la versión es más preciso, porque una bandera puede estar activada o no dentro de una misma versión del compilador. Es también el patrón que permite a un paquete público adoptar cosas nuevas sin abandonar a quien todavía usa cadenas de herramientas anteriores.