Leer una propuesta como se debe

Una propuesta de Swift Evolution parece un documento técnico y en realidad es un texto argumentativo con forma de documento técnico. Su estructura no está pensada para describir una funcionalidad sino para obligar a quien la escribe a responder, en un orden concreto, a las preguntas que un revisor competente haría de todos modos: qué duele, qué propones, cómo funciona exactamente, a quién rompes, qué más consideraste y por qué lo descartaste. Leerla como si fuera documentación es perder casi todo su valor. Leerla como lo que es —una defensa escrita contra objeciones anticipadas— convierte cada propuesta en una lección de diseño de lenguajes, y convierte el archivo entero en el mejor material formativo que existe sobre por qué Swift toma las decisiones que toma.

El encabezado, que casi nadie lee

Antes de la primera sección hay una tabla de metadatos que contiene la mitad de la información útil del documento. Recoge el número de la propuesta, los autores, el gestor de revisión, el estado actual con la versión de Swift donde se implementó, un enlace a la rama de implementación, y —cuando aplica— el nombre de la bandera de funcionalidad futura asociada, un identificador que reaparecerá en la cuarta lección de este nivel.

Los documentos siguen una plantilla común pero no idéntica en el tiempo: las propuestas antiguas tienen menos secciones porque el lenguaje aún no tenía compromisos de ABI ni modos de lenguaje que declarar, y algunas de las primeras apenas ocupan dos pantallas. Esa evolución de la propia plantilla es en sí un dato histórico: cada sección nueva se añadió después de que su ausencia causara un problema, y leer una propuesta de 2016 junto a una de hoy muestra exactamente qué aprendió el proceso sobre sí mismo.

Lleva además los enlaces a los hilos: el del pitch, el de cada ronda de revisión y el del anuncio de la decisión. Que estén ahí y no en un archivo aparte es deliberado. El documento no pretende ser la verdad completa; pretende ser la puerta de entrada a una conversación que sigue accesible. Cuando una propuesta ha pasado por dos o tres revisiones, el encabezado enumera todas, y comparar la versión revisada en cada ronda es la forma más rápida de ver qué objeción concreta obligó a cambiar el diseño.

Dónde vive el argumento

Las tres primeras secciones forman una escalera y su orden importa.

Introducción. Uno o dos párrafos. Debe poder leerse sin contexto previo y sin sintaxis nueva. Si necesitas la sección de diseño detallado para entender la introducción, el documento está mal escrito y suele ser señal de una propuesta inmadura.

Motivación. Aquí está el argumento. Una motivación sólida no dice que algo sería cómodo: exhibe código real que hoy resulta imposible, inseguro o absurdamente verboso, y muestra por qué las soluciones existentes no bastan. El criterio de proporcionalidad de la lección anterior se juega entero en esta sección, y es la que los grupos de dirección citan más veces al rechazar. Muchas propuestas rechazadas tenían un diseño impecable y una motivación que no convencía a nadie.

Solución propuesta. Presenta la idea en su forma más comprensible, con ejemplos, todavía sin rigor formal. Es lo que aparecerá en las notas de la versión.

Después llega el diseño detallado, que es la parte que casi nadie termina y donde vive la verdad. Ahí se especifican las reglas de resolución de sobrecargas, las interacciones con inferencia de tipos, los diagnósticos que emitirá el compilador y los casos límite. Una discrepancia entre la solución propuesta y el diseño detallado es la señal más fiable de que una funcionalidad tendrá aristas cuando la uses.

Hay una prueba de lectura que funciona sorprendentemente bien con esta sección: busca las palabras que expresan excepción. Cada vez que el texto dice salvo que, excepto cuando o en cuyo caso, estás ante una regla especial, y las reglas especiales son el material del que están hechos los errores de compilador incomprensibles y las preguntas eternas en los foros. Contarlas te da una medida cruda pero honesta de cuánta complejidad añade realmente la propuesta al modelo mental del lenguaje.

// SE-0296 introdujo async y await. Su motivacion no empezaba
// con sintaxis, sino con esto: la piramide de retrollamadas.
func cargarPerfil(id: ID, completion: @escaping (Result<Perfil, Error>) -> Void) {
    api.usuario(id) { r1 in
        switch r1 {
        case .failure(let e): completion(.failure(e))
        case .success(let u):
            api.avatar(u.avatarID) { r2 in
                // el manejo de errores se repite en cada nivel
            }
        }
    }
}

// La solucion propuesta se justifica sola frente al bloque anterior
func cargarPerfil(id: ID) async throws -> Perfil {
    let usuario = try await api.usuario(id)
    let avatar = try await api.avatar(usuario.avatarID)
    return Perfil(usuario: usuario, avatar: avatar)
}

flowchart TD
H[Encabezado con estado e hilos] --> I[Introduccion sin jerga]
I --> M[Motivacion: el problema real]
M --> S[Solucion propuesta con ejemplos]
S --> D[Diseno detallado con reglas y casos limite]
D --> C[Impactos: fuente, ABI, resiliencia, adopcion]
C --> A[Alternativas consideradas]
A --> F[Direcciones futuras]
style M fill:#f9e2af,color:#11111b
style D fill:#89b4fa,color:#11111b
style A fill:#a6e3a1,color:#11111b

Las secciones de impacto

Tres declaraciones obligatorias miden el coste del cambio sobre el ecosistema, y aprender a leerlas te enseña más sobre la ingeniería de Swift que cualquier tutorial.

Compatibilidad de fuente. Responde a si el código que hoy compila seguirá compilando. La respuesta aceptable por defecto es que sí, y cuando es que no, la propuesta debe explicar cómo se despliega el cambio sin partir el ecosistema, que es el mecanismo de los modos de lenguaje de la cuarta lección. Una propuesta que rompe fuentes sin ese plan no se acepta.

Compatibilidad de ABI. Pregunta si el cambio altera la interfaz binaria de las bibliotecas ya distribuidas. Desde que Swift declaró estabilidad de ABI en la versión 5, las bibliotecas del sistema en las plataformas de Apple se enlazan dinámicamente, y un cambio que altere convenciones de llamada, disposición de metadatos o el orden de una tabla de testigos rompería programas ya compilados que nadie va a recompilar. Esta sección es la que convierte ciertas ideas razonables en imposibles permanentes.

Resiliencia de API e implicaciones de adopción. Aquí se explica qué pasa cuando una biblioteca adopta la funcionalidad: si sus clientes deben recompilar, si adoptar es un cambio compatible o rompedor para quienes dependen de ella, y qué versión mínima del sistema exige. Es la sección que más importa si mantienes un paquete público, porque describe exactamente el coste que trasladarás a tus usuarios.

Leídas juntas, estas tres secciones explican una regularidad que de otro modo parece arbitrariedad: por qué tantas funcionalidades de Swift llegan con una forma ligeramente más incómoda de la que cabría esperar. Casi siempre la forma bonita rompía algo que ya no se puede romper.

// La resiliencia de bibliotecas en una linea de codigo:
// congelar un tipo es prometer que su disposicion no cambiara,
// y esa promesa es exactamente lo que una seccion de impacto declara.
@frozen public struct Punto {
    public var x: Double
    public var y: Double
}
// A partir de aqui anadir un campo rompe binarios ya compilados.
// La propuesta que introduce algo asi debe decirlo en su seccion
// de compatibilidad de ABI, no dejarlo para las notas de version.

Alternativas y direcciones futuras

La sección de alternativas consideradas es, para un lector formado, la más densa del documento. Enumera los diseños descartados con la razón concreta del descarte, y esa razón es casi siempre una restricción real: una ambigüedad gramatical, un conflicto con la inferencia de tipos, un coste de ABI, una incompatibilidad con la revelación progresiva. Quien lee solo la solución aceptada aprende una sintaxis; quien lee las alternativas aprende la geometría del espacio de diseño y entiende por qué el punto elegido es el que es.

Las direcciones futuras cumplen un papel distinto y con frecuencia se malinterpretan. No son promesas ni hoja de ruta: son un compromiso de que el diseño aceptado deja espacio para esas extensiones sin contradecirse. Su valor real es doble. Para el revisor, demuestran que el autor pensó más allá de su caso de uso. Para el lector futuro, explican por qué una funcionalidad nació con una generalidad aparentemente innecesaria, que resultó ser el hueco donde encajó la propuesta siguiente tres versiones después.

Queda por último la sección de agradecimientos, que parece protocolaria y no lo es del todo: los nombres que aparecen ahí son los de quienes objetaron en el pitch con argumentos que cambiaron el diseño, y rastrear esos nombres en el foro es una forma sorprendentemente eficaz de encontrar las discusiones que de verdad importaron.