Yes. It is very clear (?) that there should be a „core“ Swift equal on all platforms, including important „core“(*) libraries. (And I think that nobody wants „language features“ to be different on any platforms.) E.g. having to import FoundationNetworking on non-Apple platform to use URLRequest and URLSession seems strange (apart from all historical reasons), and where such cross-platform libraries exist, I would hope that Apple would also use them on its platforms (if this is possible), e.g. having to use autoreleasepool just on Apple platforms for some methods in Foundation would not be necessary if the same implementations(**) would be used.
Clearly stating where something is not cross-platform is then quite important. Maybe the developer should even be warned when using features not available on all platforms when not stating according platforms in Package.swift? (I know the current „platforms“ entry works differently. And yes, there is the „available“ notation, but this is for source code, not for compiled libraries?)
(*): Yes, this is could be read as a reference to .NET Core from Microsoft, but I do not think that it will or should go as far. For an extreme case, having the same GUI experience on all platforms is certainly not a sensible goal.
(**): At the end of this interview Ben Cohen mentioned something about using the same implementations if I understand it correctly.
As a contributor, I observed noticeably slow responses to patches around platforms apart from Darwin and Linux, even for trivial ones. This could be a result of multiple factors:
new platform maintainers often don’t have commit access;
there’s no platform manager so non-trivial changes are not easily evaluated;
there’s no CI or testing infrastructure so others don’t know if it actually works;
…
This, however, becomes a blocker for new official platform support, even if the port is pretty mature. It will take time for us to smooth out these issues by letting a specific group of people to handle it officially. (And yes, CI costs, and we’re clearly in short of it. I’m not sure if funding can help, but that’s important for new ports…)
And like how SSWG tracks its own project and evaluates others regularly, SPWG will track the state of each unofficial port, including maturity, popularity and upstreaming process, so interested users can see the progress in a more direct way.
I apologize i’m advance for my naïve perspective; but the questions that come to mind are:
How do multi-platform improvements work with integration into Swift proper? Ie, is Apple fine to i have them included? Or are we dealing with a fork all the time?
Same question for libraries/frameworks etc.
Ideally, one would want anything cross-platform to
be implemented as consistently as possible, which won’t happen without a clear plan, guidelines, rules etc.. It would be great if Apple would endorse/approve such a thing.
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.
IMO SPWG can take care of it, while Apple’s not so involved — we’re having plenty of people outside of Apple in various existing workgroups and they’re taking charge of a few important aspects of the Swift project. It’s a goal to improve cross-platform usability of standard/core/official libraries and as I mentioned in the initiative, there shall also be guidelines for other library maintainers to follow.
No no no, no fork please (of course, legally everyone is allowed to do a fork, and technically you are working in a fork to do a pull request blablabla, but you know what I mean).
I'd just like to add that I've worked two weeks in May to provide support for Swift on Exherbo. I had to pause it but I'll mainly be back on it from March 6th to September 15th 2023, to hopefully finish the packaging. I may work on it before March 2023, but I can't confirm this yet. @compnerd has been of immense help for this challenging task.
To be clear, this is no more than an initiative, instead of an announcement — SPWG is not a thing yet, but I would like to see people pushing it and finally bringing it to life.
Despite not being mentioned in the post, making Swift available on more Linux distributions is also a promising goal. Thank all of you who’re working on it!
Super happy to see this initiative. I've been trying to dip my toes in cross compiling swift a few times in the previous years without success, so i'm afraid i won't be able to help much at least in the beginning, beside writing some documentation and testing some scripts on my configuration.
Just to be clear - Windows ARM support is in many senses already there. Although not released, there are ARM64 toolchain builds, and an ARM64 SDK as well. There is a cache file available to build the ARM64 SDK
The ARM64 runtime does build, though there is a failure that needs to be investigated still in Foundation that currently causes issues with the swift-driver. The C++ driver does function properly though.
In fact, the X86 target also has been repaired for the most part. The X86 support has one known limitation: calling conventions on C functions. In particular here, SIL has a limitation that it does not properly preserve the calling convention and if the calling convention does not match the default calling convention, it will lower the calls to C or closures improperly.
The Slack was renamed from the Swift Server Slack to Swift Open Source to encompass more than just server work. The Website Workgroup also coordinate their efforts their so the more the merrier! Feel free to create public/private channels as needed
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. Will need support from the Core Team and Language Team however
I think this is a fantastic idea, and an important area for Swift to improve. Thank you for writing up this proposal!
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.
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.
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.
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.
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.
I think we need to be very explicit here about whether the focus of the platform workgroup is solely about the core language or also encompasses things like Foundation, SwiftPM, XCTest etc that aren't part of the language but still considered to be part of 'Swift' because these things certainly don't have good enough consistency across the different supported platforms
Even if I agree with basically everything you wrote, I'd just like to say that library evolution and availability annotations for third party libraries can be very useful as a subset of that 'one conceptual feature' for people shipping 'enterprise style' applications, we'd definitely want to use that and have opened a couple of cases for it:
We played with enabling .xcframework support on Linux with a fork of SwiftPM (which was trivial) and it seems to work quite nicely, although the current lack of availability annotations makes it impractical at the moment.
The ability to ship libraries with evolution mode turned on (on other platforms than macOS, Linux specifically in our case - and hopefully with availability annotations for third party libraries in the future) even if requiring the same toolchain version, would be very useful in practice...
We'd happily build our software with N compilers for distribution if needed for our customers, so don't care so much about the ABI-stability-per-toolchain-version restriction really.
Indeed. It would be a shame if at least those three you have mentioned would not be part of this proposal. Although they're technically not part of Swift, they very much belong to it for almost everyone writing code that should work on both the APPLE and the !APPLE world.
Yes, this is a good point; the proposal should be explicit about where the boundaries are. The paragraph I was responding to was focused on the compiler and mentions "language features" specifically. I think it's reasonable for this initiative to stay focused on compiler/standard library/runtime, because there is plenty of work to do there and I feel that a more focused workgroup will be more effective. It could expand in scope later to pull in Foundation/XCTest/etc.
I agree that availability annotations for third party libraries are a useful addition, but I'd consider those to be the domain of the existing Language Workgroup.
Yeah. Library evolution should be enable-able anywhere that we're dynamically linking the Swift runtime.
On the other hand, if one of the main target for the group is the Android platform, it seems like the very first use case would be to help developers port their existing ios / swift codebase to Android (simply from a market point of view). Which most likely includes heavy Foundation usage (files, network, and GCD at the minimum) as well as XCTest, etc...
IMHO scoping the group to include Foundation doesn't mean it has to work on that topic right away if there are more fundamental things to work on. It just helps to set the endgoal.
. 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.