Sé que Swift aún no es ABI estable, pero solo lo hace contar para las principales versiones de Swift?

¿Existe alguna garantía de que las versiones secundarias o de parche (en versiones semánticas) de Swift sean estables con ABI?

Supongo que no hay garantía aquí, pero solo quería verificar si alguien ha encontrado algo que detalle la estabilidad de ABI para diferentes versiones menores / parches de Swift.

Además, si utilizo un marco binario Swift compilado con una versión diferente de Swift, normalmente obtengo un error de compilación. Si no obtengo un error del compilador en mi proyecto, ¿eso significa que es seguro, o aún podría haber problemas de tiempo de ejecución con una versión ligeramente diferente (versión de parche) de Swift?

5
Adam Johns 18 oct. 2017 a las 18:24

2 respuestas

La mejor respuesta

Actualización 3

También tenemos la estabilidad del módulo, comenzando con Xcode 11, con la ayuda de los archivos .swiftinterface recién introducidos. Sin embargo, una advertencia es que el código tendrá que compilarse con el indicador -enable-library-evolution. Más detalles aquí.


Actualización 2 La estabilidad del módulo está programada para Swift 6: https://swift.org/blog/abi-stability-and-more/#module-stability

Este es un extracto del Swift repositorio.


Actualización Swift 5 viene con algo estabilidad ABI:

La versión Swift 5 proporcionará estabilidad ABI para la biblioteca estándar de Swift.


Desafortunadamente aún no. Para Swift 4, indican esto aquí: https://swift.org/ blog / swift-4-1-release-process /.

Swift 4.1 no es binario compatible con 4.0. Contiene una variedad de cambios internos que son parte del esfuerzo por estabilizar el Swift ABI en Swift 5.

Con suerte obtendremos estabilidad ABI en Swift 5

4
Cristik 23 sep. 2019 a las 17:29

Creo que primero deberíamos saber qué es la estabilidad ABI. Después de eso, su confusión ya ha sido eliminada.

Hoy, la última versión de Swift es 3.1, por lo que es probable que si envía una aplicación mañana, su paquete de aplicaciones contendrá las bibliotecas dinámicas de Swift para 3.1, sin embargo, hay muchas aplicaciones en la tienda en este momento que enlazan 3.0, 2.3, y probablemente incluso algunas aplicaciones más antiguas que vinculan 2.1 y versiones anteriores. Nada me impide descargar su aplicación (en 3.1) y mi aplicación (en 2.3) y ejecutarlas una al lado de la otra en mi iPhone con iOS 10.3, ya que ambas aplicaciones se vinculan con su propia versión incluida de Swift. Es exactamente lo mismo que tú con Alamofire 4.4 y yo con 3.0.

Cuando un idioma es estable en ABI (interfaz binaria de aplicación), eso significa que está empaquetado y vinculado con el sistema operativo en sí, en este caso: iOS. El código Swift que compila en su computadora tiene una interfaz binaria en el sistema operativo mismo en lugar de cualquier biblioteca dinámica que incluya con su aplicación. Debido a esto, Apple tiene que poder garantizar que mi código Swift, cuando se compile en código de máquina (código de bits, LLVM-IR, yada-yada), podrá interactuar correctamente con el resto del sistema operativo y (probablemente lo que es más importante) no se interrumpirá entre las versiones de iOS / Swift.

En su forma actual, la especificación y el compilador del lenguaje Swift no están en un estado en el que el equipo de Swift se sienta cómodo haciendo esta promesa de estabilidad ABI; los cambios en Swift siguen siendo demasiado frecuentes y la hoja de ruta todavía es demasiado larga. Tan pronto como la biblioteca Swift se fusiona con iOS, se vuelve mucho más difícil hacer grandes cambios.

¿Por qué eso importa?

  • Sí, el tamaño del paquete de su aplicación disminuirá porque ya no tendrá que incluir la biblioteca estándar de Swift en su carpeta Frameworks, lo cual es bueno.

  • Los cambios de idioma serán más pequeños / menos frecuentes, por lo que no tendrá que preocuparse por eventos como la migración de Swift 2 -> 3 (todavía estoy asustado por eso)

  • Los desarrolladores podrán crear bibliotecas de terceros escritas en Swift y distribuir marcos precompilados (binarios), porque ya no necesitan agrupar la biblioteca estándar de Swift en su marco y, en su lugar, se vincularán con la misma versión de Swift que su aplicación (la que viene con iOS).

1
responser 20 feb. 2019 a las 09:01