El proceso: del pitch a la decisión

Swift es uno de los pocos lenguajes de gran adopción cuyo mecanismo de cambio está escrito, es público y se ejecuta a la vista de cualquiera. Desde que Apple abrió el código en diciembre de 2015, ninguna palabra clave nueva, ningún operador y ninguna regla de inferencia han entrado sin pasar por un documento numerado, un hilo de revisión abierto y una decisión razonada por escrito. Eso no lo convierte en una democracia —nadie vota y nadie tiene derecho de veto por acumulación de mensajes— pero sí en algo poco común: un proceso donde la carga de la prueba recae sobre quien propone, donde el silencio de la comunidad cuenta como señal y donde el coste asimétrico entre rechazar una buena idea y aceptar una mala está reconocido de forma explícita en el diseño del procedimiento. Entender ese aparato es entender por qué el lenguaje tiene la forma que tiene.

El hilo del foro

Todo empieza en forums.swift.org, en la categoría de propuestas informales. Un pitch es un mensaje en prosa que describe un problema, esboza una solución y pide reacciones. No tiene número, no tiene formato obligatorio y no compromete a nadie. Su función es puramente selectiva: la inmensa mayoría de las ideas mueren aquí, y ese es el resultado deseado.

Lo que ocurre en esa fase tiene poco de burocrático y mucho de intelectual. Alguien señala que el problema ya se resuelve con una función de biblioteca, alguien recuerda que una idea casi idéntica se rechazó hace tres años y por qué, alguien detecta que la sintaxis propuesta choca con una ambigüedad gramatical existente. Un pitch que sobrevive tres semanas de ese escrutinio ya no se parece al original: ha perdido casos de uso periféricos, ha ganado una sección de alternativas y normalmente ha cambiado de sintaxis al menos una vez.

No hace falta permiso ni credenciales para abrir uno. Cualquiera con una cuenta en el foro puede proponer un cambio al lenguaje que usan millones de personas, y esa apertura radical funciona porque el filtro no está en la entrada sino en el argumento: un pitch firmado por un ingeniero del equipo del compilador y otro firmado por alguien desconocido reciben la misma pregunta, que es qué problema real resuelve y por qué no basta con lo que ya existe. Lo que sí cambia con la experiencia es la probabilidad de sobrevivir, porque quien lleva tiempo leyendo el foro ya anticipa las tres objeciones estándar y las responde en el mensaje inicial.

Conviene distinguir dos tipos de hilo que se confunden a menudo. Un pitch propone algo concreto y busca reacciones sobre esa forma; un hilo de discusión de diseño explora un territorio sin proponer nada todavía. Los segundos son frecuentes en áreas grandes y suelen preceder a varios pitch distintos que compiten entre sí. Meter una propuesta cerrada en un territorio que aún no ha tenido su discusión abierta es el error de novato más común y casi siempre acaba con el autor defendiendo detalles mientras el hilo discute los fundamentos.

Hay una segunda capa por encima del pitch que es reciente y conviene conocer: los documentos de visión. Cuando un área requiere no una propuesta sino diez —la concurrencia, las macros, el modelo de propiedad, Embedded Swift, la interoperabilidad con C++—, el grupo de dirección del lenguaje aprueba primero un documento de visión que fija el destino y el vocabulario. Las propuestas individuales se juzgan después contra ese marco, lo que evita que cada una tenga que redefender la dirección entera.

La propuesta y su ventana de revisión

Cuando un pitch gana tracción, el autor abre una solicitud de cambios contra el repositorio swift-evolution con un documento en Markdown que sigue una plantilla fija. Al fusionarse recibe un identificador de la forma SE-0000, asignado por orden de llegada y nunca reutilizado; ese número es permanente aunque la propuesta acabe rechazada.

A partir de ahí entra en juego el gestor de revisión, un miembro del grupo de dirección competente. Es quien decide cuándo la propuesta está lista, quien abre el hilo de revisión formal, quien lo modera durante la ventana —habitualmente de una a dos semanas— y quien al final publica la decisión con su razonamiento. No es un árbitro neutral que cuenta votos: es un editor con responsabilidad sobre la calidad del documento y sobre la salud de la discusión.

La revisión formal se anuncia con un mensaje que incluye siempre las mismas preguntas dirigidas a quien participa: si el problema merece un cambio en el lenguaje, si la solución encaja con el carácter y la dirección de Swift, cómo se compara con soluciones equivalentes en otros lenguajes que hayas usado, y cuánto esfuerzo has dedicado a tu propia revisión. Esa última pregunta no es retórica: un mensaje que declara haber leído el documento entero y probado la implementación pesa de forma distinta a uno que expresa una preferencia estética.

Un detalle que sorprende a quien viene de otros procesos: en la práctica una propuesta no se acepta sin implementación disponible. No basta con un diseño elegante; hace falta una rama del compilador que lo materialice y una instantánea de la cadena de herramientas que cualquiera pueda descargar para probarlo. Esta exigencia filtra por sí sola una clase entera de ideas: las que solo son bonitas sobre el papel.

El autor no tiene por qué ser quien implemente. Es habitual que una propuesta la firme quien identificó el problema y diseñó la solución, y que la implementación la aporte alguien del equipo del compilador o un colaborador externo interesado. Esa división del trabajo es sana y explica por qué figuran dos y tres nombres en tantas propuestas. También explica por qué algunas ideas aprobadas conceptualmente en el foro tardan versiones enteras en llegar: no faltaba acuerdo, faltaba quien la construyera.

flowchart TD
A[Idea] --> B[Pitch en el foro]
B -->|muere| X[Descartada]
B -->|gana traccion| C[Documento SE con implementacion]
C --> D[Gestor de revision abre ventana]
D --> E[Revision publica de una a dos semanas]
E --> F[Grupo de direccion decide]
F -->|aceptada| G[Implementada en una version]
F -->|devuelta| C
F -->|rechazada| X
style A fill:#89b4fa,color:#11111b
style G fill:#a6e3a1,color:#11111b
style X fill:#f38ba8,color:#11111b

Quién decide y con qué criterios

La autoridad final reside en el equipo central, pero desde 2022 delega el trabajo ordinario en grupos de dirección especializados: el del lenguaje decide sobre la sintaxis, la semántica y la biblioteca estándar; el de plataformas cubre el soporte de sistemas operativos y arquitecturas; el de ecosistema se ocupa del gestor de paquetes y las herramientas. Por debajo hay grupos de trabajo con alcance temático que preparan material sin decidir. Esta división existe porque un mismo comité no puede juzgar con solvencia una regla de inferencia de tipos y una política de distribución binaria.

Los criterios que aplican no están ocultos, aunque sí dispersos. Cinco resumen la mayor parte de las decisiones publicadas:

Proporcionalidad. Todo cambio añade complejidad permanente al lenguaje. La pregunta no es si la propuesta resuelve algo, sino si lo que resuelve compensa la superficie que añade para siempre, incluida la que pagan quienes nunca la usarán.

Encaje. Swift tiene un carácter reconocible: seguridad por defecto, claridad en el punto de uso, revelación progresiva de la complejidad. Una propuesta técnicamente correcta puede rechazarse por no sonar a Swift, y esa es una razón legítima documentada muchas veces.

Necesidad de estar en el lenguaje. Si una biblioteca puede lograr lo mismo con una ergonomía aceptable, la respuesta suele ser una biblioteca. Muchas propuestas rechazadas lo fueron con esta frase exacta.

Compatibilidad. Romper código existente o la estabilidad binaria tiene un coste que solo se acepta bajo condiciones muy estrictas, tema de la cuarta lección de este nivel.

Enseñabilidad. Si explicar la regla nueva a alguien que aprende exige introducir tres conceptos previos, la propuesta tiene un problema de diseño aunque el compilador la acepte sin quejarse.

// Un ejemplo de proporcionalidad: SE-0326 elimino la necesidad
// de anotar tipos en clausuras de multiples sentencias.
let nombres = usuarios.map { usuario in
    let base = usuario.nombre.trimmingCharacters(in: .whitespaces)
    return base.isEmpty ? "anonimo" : base
}
// Antes de esa propuesta habia que escribir el tipo de retorno
// a mano en cuanto la clausura tenia mas de una sentencia.

Estados y lo que significan

Una propuesta no es un interruptor entre aprobada y rechazada. Su encabezado declara un estado que conviene leer con precisión.

En espera de revisión significa que el documento está fusionado pero el gestor no ha abierto la ventana; a menudo espera a que la implementación madure. En revisión activa es la única fase donde tu opinión entra en el expediente. Devuelta para revisión es el resultado más frecuente en propuestas ambiciosas y no es un rechazo: el grupo señala qué falta y el autor vuelve con otra versión. Aceptada con modificaciones indica que el grupo aprobó algo distinto de lo que se revisó, y la decisión detalla exactamente qué cambió. En vista previa aparece cuando la funcionalidad se distribuye en un paquete antes de entrar en la biblioteca estándar. Implementada cita la versión concreta donde apareció. Rechazada y retirada cierran el expediente, pero el documento permanece publicado para siempre.

Esa permanencia es una decisión de diseño y no un descuido. El archivo de propuestas rechazadas, con su razonamiento intacto, es la memoria institucional del lenguaje: evita rediscutir lo ya discutido y permite que quien vuelva sobre el tema años después sepa qué argumento tiene que derrotar.

Hay además un matiz sobre la implementación que despista a mucha gente. Que una propuesta figure como aceptada no significa que puedas usarla: aceptada quiere decir que el diseño está aprobado, e implementada quiere decir que llegó a una versión concreta. Entre ambos estados pueden pasar meses, y el registro de cambios del compilador es la fuente que resuelve la diferencia con precisión. Cuando alguien te asegure que una funcionalidad ya existe porque leyó su propuesta, esa es la comprobación que falta.

// El encabezado de una propuesta condensa todo lo anterior
// Propuesta: SE-0413
// Estado: implementada en Swift 6.0
// Gestor de revision: un miembro del grupo de direccion del lenguaje
// Implementacion: rama del compilador enlazada en el documento
// Revisiones: hilo del pitch, primera revision, segunda revision, decision
func leer(_ ruta: Ruta) throws(ErrorDeArchivo) -> Datos {
    // Los errores tipados llegaron ocho anos despues de rechazarse
    // por primera vez, con otra motivacion completamente distinta.
    try sistema.contenido(de: ruta)
}