THINKING OUT LOUD: The Swift ABI Manifesto, Annotated.
This is the only way I’ll ever get through this 8000 word beast, so here we go.
by Michael Prenez-Isbell (this article only) and everyone who contributed at Swift Evolution (the hard parts)
The First Thousand Words
WHAT THIS MEANS: You can use multiple versions of Swift in your apps now.
WHAT THIS MEANS: The compiled module files and library files will also work across multiple Swift versions
WHAT THIS MEANS: The module file is your app. It will talk to the new stable ABI.
WHAT THIS MEANS: Your app can talk to libraries compiled with different versions of Swift now.
WHAT THIS MEANS: The ABI is kinda sorta like a runtime, except it’s a compiletime. Your ABI tells your compiler and linker how to pull everything together at the lowest levels. Every OS has a C language ABI, but Swift has to have its own. It took awhile for Swift to do this because the language had to settle down. (We are a looooong way from Swift 1.2, which I have fond memories of, reading the two books from Apple on a rainsept Lincoln Road in South Beach in February — and then realizing they were changing, well, everything. Anyway.)
So, once you stablize your ABI…
WHAT THIS MEANS: … you are totally stuck with your ABI for as long as MacOS or whatever exists. You can ADD to it, but you can’t subtract from it and you can’t change it or the whole house of cards falls down. Compilers can change internal representations of things but they can’t change the way or the formats they use to talk to the ABI. Stable ABIs are forever.
WHAT THIS MEANS: OS vendors can embed a standard Swift library, and that means that app developers (like you and me) don’t have to pack huge libraries with our app. It will be sitting right there on the operating system, version-compatible with all of Swift.
the author notes: this document is only about binary framework stability for the ABI. It is NOT about module format stability, and the author also notes you have to have BOTH before you have ABI stability.
It exists, IOW, but it didn’t get a manfesto. I guess after the first one you get tired of the subject.
WHAT THIS MEANS: Library designers have their own problems. They don’t want to have to recompile their libraries for all their users every time a new version of Swift comes out.
There are bunch of people pushing for Library Evolution. So there’s a balancing act between giving Library Evolution activists what they want, while at the same time not giving up needed design space for adding to the ABI
Here’s the Library Evolution manifesto, or whatever you want to call it.
WHAT THIS MEANS: Types have to have the same layout conventions.
WHAT THIS MEANS: Type metadata, used by reflection and tools, must have either stable memory definition or a stable API or both.
WHAT THIS MEANS: Functions and memory locations get compiled into symbols and they each need to have a unique name, and every binary citizen has to nod their heads in agreement about it. No dissent.
Because Swift doesn’t really use namespaces, however much they want to argue they do because modules (no you don’t, see C#, which really does), a lot of the names aren’t unique, so they have to use name mangling to rename the symbols.
WHAT THIS MEANS : Functions have to have agreed upon calling conventions.
WHAT THIS MEANS: Son of a gun, there’s the Swift runtime. And it’s API, too, has to be ABI compatible.
WHAT THIS MEANS: Swift also ships with a standard library and it’s API is also Swift ABI now.
That’s a wrap on part 1. We’ll continue tomorrow, and over the next week.
Until then, keep thinking out loud!
Here’s part 2:
Michael Prenez-Isbell
