Introducido con Swift 5.0 junto con el soporte para la evolución de bibliotecas, el atributo @frozen fue diseñado para resolver la tensión entre la extensibilidad de API y la estabilidad binaria. Antes de este mecanismo, todas las enumeraciones públicas en bibliotecas resilientes eran implícitamente no congeladas, lo que obligaba al compilador a asumir que las versiones futuras podrían agregar casos desconocidos. Esta suposición impedía la generación de diseños compactos y de tamaño fijo, y requería patrones de programación defensiva en el código del cliente. El atributo proporciona una garantía formal de que el inventario de casos de la enumeración es inmutable para siempre, permitiendo optimizaciones agresivas.
El problema surge cuando una biblioteca publica una enumeración sin este atributo. Swift debe tratar entonces la enumeración como resiliente, reservando espacio variable en su representación en memoria para acomodar futuros discriminadores de casos y diseños de valores asociados. Esto obliga a los switches del cliente a incluir un caso @unknown default, deshabilitando efectivamente la verificación en tiempo de compilación de que todos los estados lógicos están manejados. Sin tal predeterminado, agregar un caso a la biblioteca podría causar un comportamiento indefinido en los binarios precompilados del cliente que no tienen el código para procesar el nuevo valor de discriminador, lo que lleva a bloqueos o corrupción de memoria.
La solución radica en la anotación @frozen que establece un contrato permanente. Al marcar una enumeración como congelada, el autor de la biblioteca promete que el conjunto de casos nunca cambiará, permitiendo al compilador asignar etiquetas enteras fijas y usar un diseño de memoria estable y compacto. Esto permite sentencias switch exhaustivas sin casos predeterminados, ya que el compilador puede demostrar que todos los patrones posibles de bits del discriminador corresponden a casos conocidos. La estabilidad resultante del ABI asegura que el tamaño y la alineación de la enumeración permanezcan constantes a través de las versiones de la biblioteca, mientras que el código del cliente se beneficia de optimizaciones de tabla de saltos y del manejo obligatorio de cada estado.
// Dentro de una biblioteca compilada con -enable-library-evolution @frozen public enum LoadState { case idle case loading case loaded(Data) } // Código del cliente en un módulo separado func updateUI(for state: LoadState) { switch state { case .idle: print("Esperando") case .loading: print("Cargando") case .loaded: print("Contenido") // El compilador verifica la exhaustividad; no se requiere predeterminado } }
El equipo de plataforma en una empresa de logística estaba enviando un paquete de Swift para la optimización de rutas que exponía una enumeración TransportMode con casos para .truck, .air, y .ship. Debido a que anticiparon agregar .drone y .rail en lanzamientos posteriores, inicialmente distribuyeron la biblioteca sin el atributo @frozen. Los equipos de clientes pronto informaron que Xcode se negaba a compilar switches sin cláusulas @unknown default, ocultando errores de lógica donde olvidaron manejar .ship en los cálculos de costos de envío.
El equipo consideró tres enfoques arquitectónicos para resolver esto.
Primero, podrían mantener el estado no congelado e invertir en un análisis riguroso para asegurar que los clientes escribieran manejadores @unknown default que registraran advertencias. Esto preservaba la flexibilidad para agregar modos de transporte sin incrementos mayores en la versión, pero deshabilitaba permanentemente la verificación de exhaustividad en tiempo de compilación. También fallaba en abordar la sobrecarga del tamaño binario, ya que cada instancia de enumeración llevaba metadatos de resiliencia que inflaban los paquetes de ruta serializados enviados a los dispositivos de los conductores.
En segundo lugar, podrían reemplazar la enumeración con una estructura RawRepresentable respaldada por constantes enteras. Esto proporcionaría un diseño de memoria fijo y permitiría agregar nuevos modos sin romper la compatibilidad binaria, pero sacrificaría por completo las capacidades de coincidencia de patrones de Swift. Los desarrolladores estarían forzados a cadenas verbosas de if-else, y el compilador ya no podría verificar que todos los posibles estados de transporte estaban manejados en algoritmos críticos de búsqueda de caminos.
En tercer lugar, podrían aplicar @frozen a la enumeración y comprometerse a los tres casos existentes, creando un envoltorio ExtendedTransportMode separado para futuras expansiones. Esto eliminaría la sobrecarga de resiliencia, permitiría la compilación exhaustiva del switch y garantizaría que cada cliente manejara todos los modos actuales explícitamente. La compensación era una restricción permanente sobre la modificación de la enumeración original y la necesidad de versionado para cualquier adición fundamental.
Eligieron la tercera solución. Después de congelar TransportMode, descubrieron inmediatamente dos casos de switch no manejados en su propio panel de análisis durante la compilación. La eliminación de los metadatos de resiliencia redujo el tamaño de los objetos de ruta transmitidos en un 18%, y la clara separación arquitectónica forzó una separación más limpia entre la lógica central del transporte y los modos experimentales.
¿Por qué agregar un caso a una enumeración pública no congelada rompe la compatibilidad binaria incluso cuando el código fuente del cliente todavía se compila correctamente?
Cuando Swift compila un módulo resiliente, las enumeraciones no congeladas utilizan una representación de ancho variable que reserva espacio para futuros discriminadores de casos. Si la biblioteca luego agrega un caso, el diseño en tiempo de ejecución de la enumeración cambia; por ejemplo, el entero discriminador podría expandirse de 8 bits a 16 bits para acomodar la nueva etiqueta. Los binarios precompilados del cliente esperan el viejo diseño y contienen tablas de salto o ramas condicionales que solo tienen en cuenta el rango de etiquetas original. Cuando estos binarios encuentran el nuevo valor discriminador, pueden ejecutar rutas de código inválidas o leer memoria más allá del límite de carga esperado, causando bloqueos que las cláusulas @unknown default a nivel de código fuente no pueden prevenir.
¿Cómo interactúa @frozen con enumeraciones que contienen casos indirectos o valores asociados de tipos resilientes?
@frozen garantiza que la identidad y el conteo de casos permanezcan constantes, pero no congela el tamaño de los valores asociados. Si un caso lleva una carga de una estructura no congelada o una referencia de clase, la estabilidad del ABI de la enumeración se refiere a la etiqueta de discriminador fija, mientras que el almacenamiento de carga puede seguir utilizando tamaños dinámicos a través de punteros o tablas de testigos de valores. Los candidatos a menudo asumen incorrectamente que @frozen fija toda la huella de memoria, incluidos los tamaños de carga; en realidad, la optimización se aplica principalmente a la etiqueta, y los valores asociados pueden requerir cálculos de diseño en tiempo de ejecución si sus tipos son a su vez resilientes o contienen tamaños desconocidos.
¿Se puede declarar una enumeración congelada dentro de un módulo no resiliente, y cuáles son las implicaciones a largo plazo al hacerlo?
Sí, @frozen se puede aplicar a enumeraciones dentro de objetivos de aplicación regulares donde la evolución de bibliotecas está desactivada. En este contexto, el atributo funciona como documentación de intención, ya que todas las enumeraciones dentro del módulo están efectivamente congeladas debido a la falta de límites de resiliencia. Sin embargo, los candidatos frecuentemente pasan por alto que @frozen constituye un contrato de ABI permanente; si el módulo se extrae más tarde en un marco de biblioteca resiliente, la enumeración no puede ser descongelada o extendida sin romper la compatibilidad binaria con los clientes existentes. Marcar explícitamente las enumeraciones como congeladas durante el desarrollo inicial protege el código contra violaciones accidentales de ABI cuando la arquitectura del proyecto evoluciona.