[Filosofía de Swift #4] Swift Evolution y SE-0296

En artículos y notas de versión de Swift aparecen SE-0296 y SE-0345. async/await lleva SE-0296, mientras que la sintaxis abreviada de if let name lleva SE-0345. ¿Qué significan estos números?

Son los números de registro de todos los cambios de lenguaje incorporados a Swift. Incluso añadir una sintaxis requiere Swift Evolution, el proceso público que asigna números SE a las propuestas aprobadas. Frente a la imagen cerrada de Apple, la evolución de Swift ocurre en un registro completamente público.

Esta es la cuarta entrega de la serie sobre la filosofía de Swift. Las tres anteriores trataron sus valores—seguridad, rendimiento y expresividad, divulgación progresiva y tipos por valor—; esta explica el sistema que los protege. La filosofía necesita procesos para perdurar.

Qué es Swift Evolution — revisión pública de cambios del lenguaje

En diciembre de 2015, Apple publicó Swift como código abierto y también hizo público el proceso para decidir su futuro. El escenario lo forman el repositorio swift-evolution de GitHub y los foros de Swift (forums.swift.org).

La regla central es sencilla: para cambiar la sintaxis o la biblioteca estándar de Swift, cualquiera debe escribir una propuesta y superar una revisión pública. Ni los ingenieros de Apple ni Chris Lattner pueden saltársela. Algunas propuestas iniciales de Apple fueron rechazadas por la comunidad, mientras que innumerables propuestas externas entraron en el lenguaje.

¿Qué protege este proceso? La filosofía de las tres entregas anteriores. Toda la comunidad, no solo quien propone, verifica si una función perjudica la seguridad, rompe la divulgación progresiva o mantiene la coherencia con el código existente. La coherencia del lenguaje pasa a ser fruto del proceso, no del gusto de una persona.

La vida de una propuesta — de la idea a la sintaxis

Sigamos paso a paso el recorrido de una sintaxis hasta entrar en el lenguaje.

Paso 1: Pitch. Se publica la idea en Evolution > Pitches del foro. Las restricciones son flexibles y el objetivo es medir la reacción. La comunidad propone alternativas y señala fallos. La mayoría de las ideas se filtra o cambia mucho en esta etapa.

Paso 2: redactar la Proposal. Si el pitch sobrevive, se redacta una propuesta formal. La plantilla exige Motivation, Detailed design, Source compatibility, impacto en la estabilidad ABI y Alternatives considered. No basta explicar por qué este diseño, sino también por qué no otro.

Paso 3: adjuntar una implementación. La práctica actual de Evolution exige código funcional junto con la propuesta. La revisión no comienza sin código probado en el compilador. La viabilidad se demuestra con código, no sobre el papel.

Paso 4: revisión pública. Se asigna un responsable y normalmente hay 1–2 semanas de revisión pública en el foro. Se pregunta si el cambio resuelve un problema importante, encaja con la dirección de Swift y cómo se compara con funciones similares de otros lenguajes.

Paso 5: decisión. Tras la revisión, el Language Steering Group decide. El resultado es Accepted, Returned for revision o Rejected, siempre con motivos. Si se acepta, se fija el número SE y la implementación llega en una versión concreta de Swift.

El peso del proceso visto en casos reales

Veamos algunos casos conocidos para entender cómo funciona realmente el proceso.

SE-0296 async/await. Esta propuesta inició la concurrencia de Swift. Su dirección apareció en el Concurrency Manifesto de Chris Lattner de 2017, pero tardó años en llegar a Swift 5.5 tras propuesta, revisión y aprobación. Se evaluó junto con actor (SE-0306) y concurrencia estructurada (SE-0304), como una hoja de ruta. Las funciones grandes llegan como grupos de propuestas.

Abreviación de if let en SE-0345. Permite escribir if let name = name en lugar de if let name. Aunque es pequeña, durante el pitch hubo un largo debate sobre alternativas como if let name?. La decisión final eligió la sintaxis actual por equilibrar concisión y claridad. Incluso una sintaxis menor requiere tanta argumentación.

Los rechazos también quedan registrados. La propuesta inicial para exigir el prefijo self en los argumentos de función (SE-0009) fue rechazada tras la revisión, y sus motivos siguen en el repositorio. La comunidad consideró mayor el ruido del código que la ganancia de explicitud. Registrar los motivos evita repetir el debate.

El patrón es claro: Evolution registra tanto lo que entra como lo que no entra y por qué. Así se acumula jurisprudencia sobre diseño de lenguajes.

Quién decide — estructura de gobernanza

¿Quién toma la decisión final?

En la cima del proyecto Swift está el Core Team, mientras que el Language Steering Group toma las decisiones sustantivas sobre el lenguaje. Incluye ingenieros de Apple y miembros externos; considera las opiniones del foro, pero no decide por mayoría. Según la documentación oficial, la revisión recopila argumentos, no votos: se busca que gane la evidencia, no la voz más fuerte.

La influencia de Apple es real: la mayoría de quienes desarrollan el compilador trabaja para Apple, y necesidades de sus plataformas, como resultBuilder para SwiftUI, han impulsado propuestas. Pero Apple tampoco puede cambiar la sintaxis fuera del proceso, y todo debate queda públicamente disponible. Con el crecimiento de server-side Swift y embedded Swift, la gobernanza se divide cada vez más en grupos de trabajo.

Beneficios prácticos para desarrolladores

Conocer Evolution ofrece beneficios concretos a los desarrolladores de Swift.

Primero, el material de aprendizaje de mayor calidad es gratuito. Cuando una sintaxis no se entiende, la propuesta original es mejor que un blog. Explica el problema, la justificación del diseño y las alternativas: no solo cómo usarla, sino por qué tiene esa forma. Se puede buscar por número SE en el panel swift.org/swift-evolution.

Segundo, permite ver antes el futuro del lenguaje. El panel de pitches del foro es un avance de Swift dentro de 1–2 años. Muchos hilos actuales se han convertido en sintaxis anunciada en la siguiente WWDC.

Tercero, la participación está realmente abierta. Compartir experiencia de uso en un hilo de revisión puede acabar citado en la decisión. El feedback práctico de usuarios coreanos sobre propuestas de cadenas o formato es una contribución más valiosa de lo que parece.

Cuarto, sirve para decisiones técnicas del equipo. Distinguir una experimental feature flag, una función aprobada y una upcoming feature permite decidir cuándo llevarla al código de producción.

Resumen

• SE-XXXX es el número de una propuesta de cambio del lenguaje que superó Swift Evolution. Todo cambio de sintaxis de Swift pasa por este proceso público.
• El recorrido es pitch → propuesta, con alternativas → implementación → revisión pública → decisión del Language Steering Group.
• Apple tampoco puede saltarse el proceso, y los motivos de aprobación y rechazo quedan como jurisprudencia pública del diseño del lenguaje.
• Para entender una sintaxis nueva, la propuesta original es la mejor fuente; el panel de pitches anticipa el futuro de Swift.

Con esto termina la cuarta entrega de la serie sobre la filosofía de Swift. Hemos visto seguridad, rendimiento y expresividad, divulgación progresiva, tipos por valor y la institución Evolution. A continuación profundizaremos en la sintaxis básica, empezando por el signo de interrogación más habitual de Swift: qué son realmente los opcionales.

Seguir leyendo

• [Swift intermedio #1] ARC de Swift explicado: elige weak o unowned según las relaciones de ciclo de vida
• [Swift intermedio #2] Generics de Swift, de la introducción al uso práctico: cómo elimina duplicación y riesgos
• [Swift intermedio #3] some vs any en Swift: qué es some View y cuánto cuestan los existentials