Even better - no adoption is required. If you import Foundation on Linux or Windows today, you will be using the new implementation. You can now also use FoundationEssentials or FoundationInternationalization to get a focused subset of the complete Foundation API.
This update brings major improvements to using Foundation on all platforms, and aligns with macOS 15 and iOS 18. For Linux and Windows, here are some highlights of what's new compared to Swift 5.10:
New Swift implementations of:
URL
Data file I/O
Calendar, TimeZone, Locale
FileManager, ProcessInfo, UUID
String extensions
and many more
High performance JSONDecoder, JSONEncoder, and property list encoders. Includes support for JSON5.
FormatStyle, our Swift-first formatting and parsing APIs for dates, times, durations, numbers, lists, and more. Includes support for Swift's regular expression builder syntax.
Fast ISO8601 formatting and parsing
Predicate and Expression types, using Swift macros
AttributedString value type, with strongly typed attributes and collection and sequence-based APIs.
async/await support for URLSession
Complete audit for Swift 6 Sendable support
Please try out your projects with the nightly 6.0 toolchains and let us know how it goes. We are using GitHub issues to track bugs.
That's fantastic, thank you @Tony_Parker and team!
I'm extremely excited that this is a drop-in replacement and people are able to use the new code without having to do anything. That allows everybody to slowly migrate away from older types to everything new.
I have one minor point of confusion. The OP discusses a new Swift implementation of UUID, and the blog post says that no C-wrapping is happening. However, it does look like C is still used for some of the internal implementation details of the UUID. Would anyone be able explain the reasoning behind this, out of morbid curiosity?
There are some areas where we still need to wrap C for various reasons, but we're trying to keep it to a minimum. Any place where we do use it, we should be looking to remove it over time where we can.
For UUID specifically, I should have been more clear -- the UUID type in foundation-essentials is now used to back all NSUUIDs on Darwin, instead of the previous Objective-C one. That's done via a new concrete subclass here. This is an example of where we're striving to use just one implementation for all platforms wherever possible, even if we have to put in some layering for Objective-C. We hope that reduces differences and increases quality.
One more example of this strategy. We still depend on ICU for much of our date and time formatting logic. However, as part of this project we implemented the Gregorian Calendar without depending on ICU. This allowed us to sink API like ISO8601 formatting into our lower-level library and not require bringing in the whole ICU stack for these common operations.
So ... if I understand correctly, what this post is about is that swift-foundation is now included in non-Darwin toolchains as well?
And more importantly, am I right to think swift-foundation hasn't overtaken corelibs-foundation just yet? But there are a nice amount of declarations in corelibs that export the swift-foundation one (which is great)?
I notice there are no snapshot tags for this repo or for swift-foundation-icu yet. Those will need to be added for people building a particular snapshot of the toolchain, likely by Mishal, otherwise update-checkout will randomly check out some other commit.
@Tony_Parker or @jmschonfeld can correct me if I'm wrong, but I believe everything implemented in swift-foundation is the same implementation being used for Darwin.
This is also the goal going forwards--as swift-foundation grows, we will end up with Foundation being just swift-foundation plus some stuff that only makes sense on Darwin for whatever reason.
Way back in the day on the objc-language mailing list, which I'd link to but it appears the whole mailing list, and its archives, have all disappeared off the face of the Web, we used to be told by Apple devs that whether the existing Foundation APIs put things on the autoreleasepool was something that, even in the post-ARC world where autorelease was much less relevant, couldn't be changed, for the sake of binary compatibility, since MRC Objective-C apps could conceivably expect certain things to be autoreleased, and that the autorelease behavior of Foundation APIs essentially formed a contract of sorts. Is it safe to assume that that is no longer the case and that we can start expecting to be able to use Foundation without autoreleased objects being generated all over the place anymore? ( if true!)
It's still true that sometimes code using Foundation API relies on values being autoreleased. In some cases we are able to change it and there is little or no effect. In others we found regressions, so we put in compatibility checks. That means the behavior changes when the process is linked against a newer SDK. We may also just retain/autorelease the result in Objective-C before passing it back to Objective-C clients.
Other compatibility issues we saw included assuming the result of an API is a mutable instance (even if the return type is NSArray, e.g.) or passing nil to non-nullable API and getting away with it. Swift offers a lot less leniency in these kinds of things, which is really useful as a library author.
Also, using Swift in the implementation means that interior objects are not autoreleased (even if the final result must be) and therefore the peak memory usage is sometimes lower vs. an Objective-C implementation.
Are there things in Foundation which you'd rewrite in Swift but specifically not open source, or are they just bits which are so low priority for porting that they'll probably never happen? Even if something could never be useful on any other platforms having the source available is sometimes helpful.
Thanks for the info. I was more wondering about the general progress that has been made, otherwise Darwin changes don't affect me much considering I mostly do Server Side.
I can see it can be hard to quantify though. I was just curious.
I'll take the silence as a yes
The post's title was a bit confusing to me at first.
CoreFoundation, the C library that was used as the base for Foundation on both linux and macOS before, is no longer built in the swift-corelibs-foundation repo. Incorrect, it has merely been moved into Sources/, and is clearly still built on the linux CI. Some files from swift-corelibs-foundation have been deleted though, like Data.swift, in favor of code from swift-foundation.
As for what percentage of APIs remain the same, whether in signature or implementation, I can't say. Maybe some tooling like swift-syntax could be used to automate and answer that question.
if true!)