Initiative: Swift Platform Work Group

[Douglas_Gregor]

@stevapple

Swift Platform Work Group (tentatively named) is a new Swift community workgroup, working together to improve platform usability of Swift.

I think this is a fantastic idea, and an important area for Swift to improve. Thank you for writing up this proposal!

@stevapple

• Improving Swift toolchain experience on existing platforms. Different platform and toolset may have different behavior, and Swift tools should handle these differences for users. The ultimate goal is a unified yet native cross-platform experience, including cross-compilation experience.

Others have noted how this intersects with the proposed Swift Tooling Workgroup. I recommend narrowing this bullet point to reduce the overlap and provide more focus for this effort. What about something like:

• Simplify cross-compilation from any host: From any host toolchain, it should be easy to cross-compile to another target given the appropriate SDK, without having to build a complete, separate toolchain.

@stevapple

• Empowering Swift compiler for existing platforms. Currently, Swift has many language features that are not available for Linux and Windows. This includes restricted platform module, missing API availability and, ultimately, library evolution and ABI stability.

To the best of my knowledge, Swift's language feature set is consistent across the various platforms. The difference with Apple's platforms is that they are the only ones shipping ABI-stable Swift, because the Swift standard library and runtime is part of the OS. Platform API availability, library evolution, and ABI stability are all part of one conceptual feature, and if some other platform were to choose to ship an ABI-stable Swift, that would involve adding it as a platform with version mappings between platform version and Swift version, along with enabling library evolution for the Swift standard library. That might be a reasonable thing to do, but I don't consider that to be "Empowering Swift compiler for existing platforms."

I recommend either removing this bullet or narrowing it down to something focused on bringing ABI stability to additional platforms. I'm mixed on whether other platforms actually need ABI stability at this point.

@stevapple

And, in its current state, SPWG won’t:

• Invest in Apple platform support. Swift functionalities and experience on macOS and other Apple platforms are mature, compared to other platforms. Moreover, modifications to Swift toolchain on macOS may impact Xcode support and OS release, which is not open-source and thus uncontrollable. However, we’re willing to collaborate with related teams in focused areas like cross-compilation.

I totally understand where you're coming from here, but with my Apple hat on... I'd rather this bullet not be part of the proposal. The changes we all make to Swift on GitHub make it into the toolchains Apple ships in Xcode and uses in its OS platforms.

@stevapple

Invest in low-resource and bare-metal platforms. Although this is also an inspiring area, such platforms are different from others and the work is more specific. A new workgroup has been proposed to exploring this area and SPWG will work with them if necessary.

I think low-resource and bare-metal platforms will benefit greatly from the initiative you are proposing, but I agree that it's a separate thing. It's good to stay focused.

@0xTim

@stevapple

Swift is an open-source effort, which should be open to any reasonable improvements, instead of having explicitly what Apple needs. New platform support, of course, can be upstreamed. Windows support is exactly the case, and SwiftWasm upstreaming is in progress. Eventually we should merge mature ports into mainline and announce them as officially supported.

A stated goal of the group IMO should be to get the current ports merged into mainline and importantly CI set up too. That makes adoption on those platforms significantly easier and better long term.

I agree with this . I would like the barrier for a port to be part of the main GitHub repository to be fairly low, so long as it's not breaking CI or causing problems elsewhere, and have ports mature in-tree. The overhead of maintaining separate toolchains for a port is fairly high (e.g., half of SwiftWASM's diff with the main Swift repository is in build/CI configuration), and it makes it unclear where one should start if they just want to try out Swift.

Doug