¿Qué estructura de metadatos específica utiliza Swift para mantener la estabilidad del ABI al agregar propiedades almacenadas a estructuras resilientes?

Respuesta a la pregunta.

Swift mantiene la estabilidad del ABI para estructuras resilientes almacenando los desplazamientos de campo en metadatos en tiempo de ejecución en lugar de codificarlos como valores de desplazamiento inmediatos en los binarios de los clientes. Cuando un módulo exporta una estructura no congelada, el compilador genera código que accede a las propiedades almacenadas a través de una Tabla de Desplazamientos de Campo incorporada dentro de los metadatos del tipo. Esta indirection permite a los autores de bibliotecas agregar nuevas propiedades almacenadas en futuras versiones sin invalidar los binarios existentes compilados con disposiciones de estructuras más antiguas. En contraste, las estructuras @frozen utilizan el cálculo de desplazamientos directos, lo que produce un acceso a la memoria más rápido pero congela permanentemente la disposición. La compensación es un ligero costo de rendimiento debido a la carga adicional de memoria de la tabla de desplazamientos en comparación con la direccionamiento inmediato.

Situación de la vida real

Imagina diseñar un núcleo de SDK de Analytics distribuido como un marco dinámico a cientos de aplicaciones clientes. El SDK define una estructura Config con inicialmente dos campos: apiKey y environment. Seis meses después del lanzamiento, los requisitos del producto exigen agregar los campos retryPolicy y timeoutInterval a esta estructura.

// En AnalyticsSDK (Módulo A) - Inicialmente compilado
public struct Config {
    public let apiKey: String
    public let environment: String
    // Nuevos campos agregados en v2.0 sin @frozen:
    // public let retryPolicy: RetryPolicy
}

Si la estructura fuera @frozen, este cambio haría que las aplicaciones clientes existentes fallaran porque codificaron el tamaño de la estructura y los desplazamientos de campo durante la compilación. Consideramos tres enfoques para resolver este problema de evolución. El primer enfoque implicó convertir la estructura en una clase, aprovechando la asignación en el montón y la estabilidad de punteros; esto preservó la compatibilidad del ABI pero introdujo una sobrecarga indeseable de conteo de referencias y una semántica de referencia que rompió las garantías de inmutabilidad de los tipos de valor. El segundo enfoque sugirió enviar una estructura paralela ConfigV2 mientras se deprecaba la original; esto mantuvo la compatibilidad pero fragmentó la superficie de la API y obligó a los desarrolladores a migrar explícitamente. El tercer enfoque adoptó estructuras resilientes al eliminar el atributo @frozen, permitiendo que el compilador emitiera accesos indirectos a los campos a través de búsquedas de metadatos.

Elegimos la tercera solución porque equilibraba el rendimiento con la flexibilidad futura. Los binarios de los clientes continuaron funcionando sin recompilación porque consultaban dinámicamente los desplazamientos de campo de los metadatos del SDK en tiempo de ejecución. El resultado fue una evolución sin problemas de la estructura de configuración a través de las versiones del SDK, aunque documentamos que los campos de configuración a los que se accede con frecuencia deben ser almacenados localmente para mitigar el costo de indirection extra.

Lo que a menudo les falta a los candidatos

¿Cómo determina Swift el tamaño y la alineación de una estructura resiliente al compilar el código del cliente que importa el módulo definitorio?

Al compilar contra una estructura resiliente, Swift no puede conocer el tamaño o alineación concretos de manera estática porque podrían añadirse nuevos campos más adelante. En cambio, el compilador genera código que consulta la Tabla de Testigos de Valor (VWT) asociada con los metadatos del tipo en tiempo de ejecución. La VWT proporciona funciones para tamaño, alineación, paso y destrucción, lo que permite al cliente asignar la cantidad correcta de espacio en la pila o memoria del montón sin conocer previamente la disposición de la estructura.

¿Por qué cambiar a un enum resiliente requiere una cláusula @unknown default y qué sucede bajo el capó cuando se agrega un nuevo caso?

Los enums resilientes no exponen su lista completa de casos a los módulos importadores, lo que impide cambiar exhaustivamente sin una cláusula default. Cuando el autor de la biblioteca agrega un nuevo caso, los metadatos del enum se actualizan para incluir el nuevo valor de etiqueta. El código del cliente compilado con @unknown default puede manejar esta etiqueta desconocida en tiempo de ejecución cayendo en la rama por defecto, mientras que los enums congelados caerían en errores por etiquetas no reconocidas porque la declaración switch fue compilada como una tabla de saltos sin opción de recuperación.

¿Qué optimización específica proporciona el atributo @inlinable a través de los límites del módulo y por qué rompe la resiliencia?

@inlinable expone el cuerpo de una función o método al compilador del módulo importador, permitiendo la inclusión de código entre módulos y la eliminación de código muerto. Esto rompe la resiliencia porque el compilador del cliente incorpora los detalles de implementación directamente en el binario del cliente. Si el autor de la biblioteca cambia más tarde la implementación, el cliente seguirá utilizando el antiguo código inlined, lo que puede causar divergencias de comportamiento sutiles o bloqueos si las estructuras de datos internas cambian.