Add an ABI Stability vision document. #2510
Conversation
This talks about ABI stability and where we'd like to go with it for Swift.
| runtime by the component they were linked with. | ||
|
|
||
| End users of consumer operating systems, including both Apple and | ||
| Microsoft platforms, tend to take ABI stability for granted; that is, |
There was a problem hiding this comment.
Is it as true for Microsoft/Windows? I know they're moving toward a "universal C runtime" so this may not be as true in the future (though certainly still true for the C++ runtime), but you still end up bundling the language runtime DLLs in the application bundle next to the executable so it's less ABI stability and more, "you pack the runtime you built against so there aren't ABI conflicts"? Sort of like snaps or how we used to ship the Swift standard library on Apple platforms before we had ABI stability.
There was a problem hiding this comment.
:-) It's complicated.
The C runtime on Windows isn't tightly coupled with the OS in the way that the C library on Darwin or Linux is; system components don't use the same C runtime library that applications use, and it's totally possible to write programs that just use the Win32 API and don't use the C runtime at all (or very little, at any rate).
So yes, programs will often install a C runtime library somewhere (hopefully, these days, not in C:\Windows\System32) and not share that with other programs or the rest of the system, but the underlying system API is ABI stable.
There was a problem hiding this comment.
(This does have some interesting implications for Swift C++ interop on Windows, in that it means that user code would need to be using the same C/C++ runtime as the Swift runtime. Similarly if anything uses Swift runtime functions that return malloc-ed memory and so on.)
| so the major versions of packages in major versions of those | ||
| distributions are fixed, but one distribution's set of packages | ||
| may bear little relation to another's. In this case, | ||
| `@availability` annotations could perhaps be used for the system C |
There was a problem hiding this comment.
It would be great to have an actual Swift-version availability annotation that doesn't map back to an OS version.
rjmccall
added
PSG
Also mention that the C/C++ runtime isn't part of the ABI boundary on Windows, and that SEH unwinding can happen for asynchronous exceptions.
| intend to set a high bar for declaring ABI stability. As such, to | ||
| become officially ABI stable: | ||
|
|
||
| 1. The Platform Owner will raise a Swift Evolution proposal for |
There was a problem hiding this comment.
What is a "Platform"? Is "Linux" a platform, or are "Debian", "Fedora", and "Arch Linux" separate platforms? At least between Debian and Arch, there is a considerable difference in their release strategies that impact the ABI stories, ranging from, "libraries should be held stable for one or two releases" to "rolling-release. ABI is whatever you happened to have downloaded at the moment. Partial-upgrades are not supportable".
There was a problem hiding this comment.
I think Linux probably is a platform, but I appreciate it's a complicated case and will require some special handling.
There was a problem hiding this comment.
I suppose it's pertinent to that discussion that the proposal in the draft Vision Document is that, for Linux, Swift should be ABI stable at its top surface (Swift runtime/standard library and core libraries, as well as code built with the Swift compiler itself), rather than that we're trying to somehow achieve ABI stability across the board for any library you might choose to use — the latter is effectively impossible because of the problems you point out (different distros taking different approaches, some libraries not really having good ABI stability themselves and so on).
There was a problem hiding this comment.
I'm 100% on-board with nailing down the calling conventions, but still have questions about the library ABI/binary compatibility story.
Will we be requiring full bi-directional binary compatibility like on Darwin where you can build against a new runtime and run it on older runtimes (assuming minimum deployment targets work out) as well as building against older runtimes and running it on newer runtimes?
Or are we okay with something more like glibc/libstdc++ where something built against the older runtime will continue working on newer runtimes, but not the other way around?
There was a problem hiding this comment.
Personally I think we should aim high here; if we can make Swift itself work the way it does on Darwin, that's actually quite a compelling feature for Linux development — Swift programs won't have the deployment problems that C/C++ programs do.
I realise that's not easy and will require @availability support and some kind of Swift minimum target version support from the compiler too.
This talks about ABI stability and where we'd like to go with it for Swift.