So it would be time to include the new swift-foundation in the toolchains for Linux and Windows? How to avoid that swift-foundation has different versions in those toolchains and on macOS? What is the strategy, how to use swift-foundation now and in the future?
1 Like
Linux and Windows can use the new Foundation as a package, as outlined in the repo. Presumably it could replace the existing version once the API is complete enough.
3 Likes
This might be OK for now, but in the long you probably do not want this, because even simple Swift programs then might not work on all platforms. Also, the question about how to be sure that that same version of the new Foundation is used is still not clear to me. I cannot find anything about those questions in the README of the GitHub project, and not in the according blog entry.
3 Likes
I'm not sure what you mean. Even simple Swift probably might not work across platforms now, and I don't see how swift-foundation changes that. In fact, it probably makes it better, at least for the APIs it covers, as you can now finally use the same implementation on other platforms that Apple does on theirs.
2 Likes
Now you can write import Foundation, and if you do not happen to use details of the old Foundation where the implementation differs, you can compile a simple program as-is and it runs on Mac, Linux, and Windows. And because currently some details of the implementation differ, you want to have the new Foundation so that a failing of the compilation or a different behaviour does not happen (where it is not expected for some other, more explicit reason).
If you then use something like import NewFoundation (or an import of a part of it) on macOS, this will not compile on Linux or Windows because the new Foundation is then not a part of the toolchain and has to be included as a package. So a very simple program “from the book” will compile on macOS, but will not compile on Linux or on Windows.
You then will have to choose explicitly that your little simple program should be cross-platform, so you include the new Foundation as a package, what is kind of silly for running it on macOS, because there the new Foundation is part of the system. So you start using conditional imports and conditional uses of packages. This is very fun for a beginner I guess…
Simple command-line programs that do not anything platform-specific should work in a simple manner on all supported platforms. And there should be some way to have “control” over the versions of the new Foundation that you address (whatever that actually means).
2 Likes
You're rather begging the question here with the assertion you're not using any of swift-corelibs-foundation where the implementation differs. Not only is that rather rare but it's a silent time bomb in your codebase, as there's no indication you're using something that can differ across platforms. To my mind nobody should be using Foundation across platforms right now, at least not without deep thought about the APIs being used and a review of the implementation to ensure it's complete.
On Apple platforms you can't import the new Foundation explicitly, it just silently replaced parts of the existing Foundation. The module names only exist as part of the package right now, which work just fine on macOS. So if you choose to start using it, it would be exactly the same code on all platforms. Once they start rewriting the FoundationNetworking module in swift-foundation they'll have to decide what to do about the old version, as that's the first module that will conflict with an existing name. Theoretically they could just silently replace bits in swift-corelibs-foundation with the rewritten source but so far they've said nothing about their plans. Personally I just ignore the existence of swift-corelibs-foundation.
Except some places where there are missing things or a different behaviour in some details (e.g some regex expressions might work differently, but after a while you know those spots), this is very feasible, a lot of people are doing it (e.g. think String manipulations in a web application on Linux) and what other options have there been?
For me the new Foundation is the promise that those “unnecessary” differences will go away, from what you tell me it more a less sounds too me that Swift — even on a basic level — will never be cross-platform. I think Swift is already cross-platform on a basic level when using the old Foundation but with some caveats and I understood the new Foundation such that the cross-platform question will be fully resolved (so to speak) on that basic level.
1 Like
I'm not sure what I've said that could be interpreted as Swift never being truly cross platform. And the new Foundation is definitely a step towards more reliable cross platform Swift. But so far Apple has said nothing about when they'll replace swift-corelibs-foundation with swift-foundation and I don't expect them to until they announce the full transition.
1 Like
OK, just the impression, sorry if misinterpreting.
Somehow this is my initial question. So I guess we have to wait (if not someone who knows more would like to answer here).
Thank you for your answers.
(just citing)
2 Likes
The short answer is that we do not (yet) have a complete plan on how to best replace swift-corelibs-foundation usage with swift-foundation. There are some challenges that will need creative solutions and collaboration in the Swift-on-server community. You have identified a few of them. In order to get there, though, we're working incrementally.
Right now we are building the fundamentals that we need in order for the package to be a viable replacement in the first place:
- Develop a high-quality Swift implementation of our most important API
- Use that Swift implementation in the most widely-deployed version of Foundation (iOS, macOS, et. al.).
- Add new Swift API in collaboration with the community (e.g. the new Calendar API pitch).
As touched on in the other thread, we are well on our way. The code in our GitHub repository has indeed shipped as part of iOS 17 and macOS Sonoma. That includes our new, dramatically faster implementations of JSONDecoder and Calendar. Shipping as part of a major OS release is also an incredible stress test for these implementations. They are in constant use on millions of devices in a wide variety of configurations.
The reason we have not tagged a release of the package yet is simply because we are being conservative about declaring a 1.0 as ready for use. There are a few more key APIs which we need in order for the package to be broadly usable on Linux. On Darwin we can fall back on Objective-C or C implementations to fill those gaps, but for the package we want the implementation to be as much Swift as possible.
Thanks for the questions, and I hope this helps to clarify.
18 Likes
It would be very useful to tag 0.x releases as development progresses (perhaps for each type reimplemented?) and apple-2023 (or similar) tags for the versions that actually ship as part of Apple's OSes, so that devs can track the implementations that are fully cross platform.
22 Likes
Agree that would be helpful, especially the ones matching major OS releases (we do the minor basically ourselves by forking and releasing our own versions which works ok).
Really looking forward to having this transition move forward though, the extra build time currently incurred by building foundation is a bit painful (we will likely try to wrap it up as an xcframework, which is problematic on Linux - need to run our own toolchain then such that SPM can support it locally for the single distribution version we target… here’s hoping for support for binary dependencies on Linux 
).
1 Like
if you want to gather feedback from real-world linux users, or at least the ones using SPM, you must tag semver releases. (fyi, this is not a requirement linux users made up, it is a requirement SPM made up.) how else will real-world linux users adopt your package? this is a bit like launching a website and expecting users to access it through an IP address because you think it is too early to choose a domain name for it.
4 Likes
I haven't looked at sales/market figures for a while, and I have no idea what portion of devices run the latest OS, but this itself feels like a very conservative estimate, no? i.e., in February active devices were over 2 billion: Apple reports first quarter results - Apple
I get it, but given the above, isn't it already in use? Linux numbers are likely a drop in the bucket compared to what's already out there.
Thanks for the feedback @Jon_Shier - we will certainly consider this.
5 Likes