Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
It is not, but it's like 95% of the way there in my experience - most things that are missing are relatively recent additions that have some complex OS interactions, like filesystem I/O with language-level concurrency features.
> Does this change imply better (eventual) support on non-Darwin systems?
Yes. The non-Darwin Foundation version is already rewrite that takes a lot of effort to keep in lock-step with the closed-source Objective-C version, so unifying the implementations in Swift will both reduce the amount of maintenance effort and promote non-Darwin platorms to more of a "first-party" status.
> Also, is Foundation the same thing as what one might normally term a standard library?
It's more of a standard library++, including some things that other languages include in their standard libraries (Date/Time models) but also other things that are common to put in third-party libraries (networking, etc.). You do not need to use Foundation for basic things like arrays or concurrency that are built into the normal standard library.
Do you mean like io_uring? That wouldn't be too surprising. Even Go doesn't have that in the standard library yet.
> so unifying the implementations in Swift will both reduce the amount of maintenance effort and promote non-Darwin platorms to more of a "first-party" status.
That's what I was hoping for. Thanks!
I'd call that a language feature. Or maybe with Swift there is a blurry line between the two?
https://github.com/apple/swift/blob/main/stdlib/public/core/...
Swift is fantastic, and by far my favorite language to write client code in. (Compared to Rust, TypeScript/JS, ObjC, C++, C#, & Java.)