I know that blog post sounds like ABI stability is a goal in and of itself, but that’s not necessarily true. ABI stability lets you do one thing in particular: closed-source libraries don’t need to be recompiled when the compiler changes. That’s useful for people who write closed-source libraries, and it was certainly requested fair amount leading up to Swift 5, but for everybody else it doesn’t matter so much. Library evolution likewise allows closed-source libraries to depend on other closed-source libraries, and apps to depend on libraries outside their “app bundle” (on Windows, the program directory)
What was different about Apple is that Apple wanted to use Swift in the OS, and always did. That’s why Swift jumped through so many hoops to get library evolution working; not just the availability model, but the part where libraries could change out from under an already-built app without breaking ABI. I don’t think there’s any driver of that from Microsoft at this time, and I don’t think there’s likely to be since their everyday platform APIs are for the CLR, not compiled to native code. But I fully admit I don’t know much about the Windows development situation these days.
So without that, the main driver of ABI stability + library evolution would be so multiple apps could share common libraries without duplicating them. The main driver of ABI stability without library evolution (but also included in the above) would be distributing closed-source libraries for app developers. Are either of those important enough goals on Windows that we want to lock ourselves in? Commit to everything public having the memory layout it does, using the runtime functions and calling conventions it currently has? We’ve talked idly before about making classes COM-compatible on Windows; should we give up on that, or limit it? Those are the kinds of questions to ask for deciding when to commit to an ABI.
For Apple, the answer was obviously “yes, eventually”, and because of that there are some suboptimalities in the Swift 5 ABI. Some get worked around with deployment targets, as a proxy for the runtime version, but others are stuck forever. For Linux, the answer thus far has been “no, it doesn’t provide enough benefit”, because there’s not nearly as big a closed-source library ecosystem, particularly not for the server focus Swift has gone with. For Windows? I trust @compnerd to evaluate whether the benefits make it worth it, but at the moment I don’t see a strong reason to push for it.
But maybe I’m just missing it. What would you, specifically, do with a stable ABI on Windows, that you can’t do today?
P.S. As discussed, Swift ABI stability does depend on the underlying C ABI being stable*, but that isn’t really the main concern; glibc is pretty stable in the forward-compatibility direction, but that doesn’t automatically mean we want to stabilize the Swift ABI on Linux.
* Technically I think this is a library limitation more than a language limitation; I believe you could define the Swift ABI without referring to C at all, but as soon as you call a function provided by a C-based library, from memory allocation to I/O to COM to a custom library, you’re back depending on C again.
P.P.S. There’s another benefit to ABI stability, which is writing cross-language bridges that don’t go through C. But while that’s not an anti-goal for Swift, it isn’t really something the project has focused on either. It’s technically possible but in practice only the Swift compiler can really tell you how to call Swift APIs, so any tool that interoperates with Swift is likely to do so very narrowly anyway, or embed SourceKit / the compiler in the tool itself. But I digress.