Question: Is Swift ABI stable on Windows? How far are we from there?

[compnerd (Saleem Abdulrasool)]

@Douglas_Gregor

I disagree that it's a non-goal. It's not something we should rush into, and we've had to tweak the Swift ABI on Windows a little bit as support for the platform matured. Once that calms down (and I think it has [*]), we should consider the merits of providing ABI stability for that platform.

I would now agree with you. The original statement from ~2022 was reasonable then. I think that we have seen a significant amount of maturity gained in the Windows toolchain. I don't think that we are quite ready to pin down ourselves yet, but we are making great progress towards that end. In the mean time, new avenues of resolving some of the older problems have now become viable

As to the Concurrency ABI issue - word is that it should be possible and this might just be an artifact of LLVM itself.

@Douglas_Gregor

We try not to customize Swift all that much for each platform, because it makes ongoing development and porting to new platforms harder. The memory layout and Swift runtime calls we make are not likely to diverge much across platforms, so ABI stability on one family of platforms gets us most of the way there for all of the other platforms so long as we don't diverge.

I mostly agree with this, but we have seen a significant chunk of Swift exclude Windows as a host due to its decisions. That does result in a good deal of divergence. One area that I would actively want to diverge though would be the object layout. I think that it would be good to consider object layouts which are COM friendly by default.

@Douglas_Gregor

Right, this is a good question. COM-compatible support would be nice, but absent an actual plan to do it, it shouldn't block us from introducing ABI stability.

I think that it is less a plan and more so the lack of ability to execute on it due to the continual stream of Windows behind left as an exercise for the interested party that prevent this. I would say that this is a completely reasonable thing to hold ABI stability on. (If you want more than a vague statement, the early swift-driver is a great current example. Macros were something which required last second heorics on Windows by me to get them into the releease).

@Douglas_Gregor

I think this implies a move toward using the Swift runtime version for #available checks rather than vendor OS versions. On Windows, for example, an ABI-stable Swift standard library isn't likely to ship in the OS, so I wouldn't expect an #available(Windows 11...) anywhere. I'd propose that we move to using #available(Swift 6.2) or similar for cross-platform APIs, then have an optional mapping to a vendor platform version for vendors that do ship them, e.g., iOS 26 -> Swift 6.2. In this world, one could use #available(iOS 26) to access an API with Swift 6.2 availability, but not the opposite. Should Swift ship as part of some other OS at some point (Ubuntu or whatever), we could add Ubuntu 2027.4 -> Swift 7.0 or whatever.

I think that this is reasonable. I think that once the early swift-driver is enabled, @available being usable with Windows would be a good item to tackle. Unlike #available, this would use the OS spellings so that we can cluster system APIs for releases that we are targeting,