We are happy to announce the release of Swift 5.10.1 for Linux and Windows.New downloads are available on Swift.org - Install Swift
Release Note
It's good to see Debian now on the supported distros list, but it seems there's still no native support, merely tarballs and Docker images (as opposed to e.g. apt install swiftlang). Why is that?
It seems like it would be good to have (deb and rpms) but itâs actually not common to have programming tool chains packaged for distributions officially. Look at Go and Rust as examples. Instead, they are investing time into a Swift version manager called Swiftly. Itâs awesome if you havenât checked it out yet!
Hmm, it's all I've ever used, e.g. with Python.
I'm aware of Swiftly, but it just extends the problem to now having yet another tarball to manually manage.
In my experience pretty much every Linux system has a robust, built-in way to essentially apt update && apt upgrade automatically, periodically. Having to build a bespoke setup just to keep Swift up to date is not great.
Well if you DO want deb packages for Swift, look no further than the Swift for ARM project. They are building for Debian and Ubuntu x86_64 and arm64 as well. Not officially supported but works like a charm.
https://swift-arm.com/installSwift
I somewhat doubt Apple will officially maintain their own repositories with deb and rpm packages, but that does not stop the community from doing this! 
Right, and that's what I use. It works great. The problem is, practically nobody new to Swift is going to use it because they have no reasonable way to know about it, since it's never mentioned on swift.org.
It'd be great if the Swift-ARM community effort were highlighted on swift.org, and included in the 'how to install Swift' pages.
I think it's due to lack of cooperation between Swift developers and Linux distributions maintainers. Or lack of effort from Swift developers to create and propose proper packages for Linux distributions.
For me personally, tarballs are OK (but Docker images are not).
At which point will Windows ARM be on the list of supported platforms and available on the download page? According to this ticket ARM support seems to be âreadyâ.
See @compnerd's earlier answer to me. After following your link, I see now that they have been putting out unofficial Windows AArch64 trunk toolchain installers since last September, including for the 5.10 branch. I suggest you try those out and report any problems you find to them.
I agree, that would be nice. Maybe something that can happen in the future as part of the platform steering group work.
How can I know which version of CoreFoundation is included in the 5.10.1 release?
The swift-corelibs-foundation repo used in the linux/Windows OSS toolchains but not on macOS is open source, so you can look in the 5.10 commit log for that info. Scrolling through and looking for large merge commits, I see this giant Monterey merge commit on the second page, from three years ago.
I'm interested in Linux actually. I thought that the swift-corelibs-foundation 5.10.1 release would be contained in Swift 5.10.1, but that doesn't seem to be the case. Now I wonder how the update cycle works there.
It should be: you're saying the released 5.10.1 library in some official linux toolchain was not built from this source tag?
I use the Swift 5.10.1 Docker image and try to compile the code
await URLSession.shared.data(for: request)
in a CI environment. Async methods on URLSession were added only recently, but should be part of the 5.10.1 tag. Yet, the compiler complains like error: value of type 'URLSession' has no member 'data'. So I assume this code isnât part of the toolchain. So far it isnât obvious to me where to find whatâs actually included.
As far as I can tell, the patches for adding the async data were never a part of 5.10.
5.10.1 is a patch release on 5.10, so it doesn't contain new feature work, just bug fixes on the existing functionality. It should be in 6.0 and main though.
Official trunk snapshot toolchains for Windows arm64 were just added a couple days ago, try it out and report any problems you run into.
You can blame me to a certain extent. Debian has a very large and complex set of policies for packages governing all manner of things and no package is allowed in until they are approved. For example, every single file in the package must be listed in debian/copyright with the appropriate attribution, if Debian ships with a library or tool then it must be used instead of the Swift provided version (eg. Ninja, icu, yaml). And then how to get around the problem that a long time ago someone else added a package to Debian with a binary named "swift"? None of these are issues for people cranking out .deb files for you to install.
At any rate, in early 2019 someone first made the request to add Swift to Debian but it sat there for about 4 years. Then I picked it up and after many months of effort I finally got 5.6.3 into Debian unstable and testing. 5.6.3 was the latest version available when I started my work. Somewhere along the way someone updated glibc and I didn't notice that Swift was FTBFS as a result so a month later Swift was kicked out of Debian testing. I've since managed to package 5.7.3 and it is now available in unstable and testing. I've been working on 5.8.3, but am getting some very odd compile errors that I've yet to resolve. I'm only one guy working in my spare time so when I can't find a ready answer or others don't have any suggestions to help me the effort stalls out till I have a day or two free to dig into it.
You might be thinking why not jump all the way up to 6.0 and get that in before the Debian 13 freeze. That would be great, but it means building 6.0 with Swift 5.7.3 or doing some bootstrapping, neither of which is supported or guaranteed to work. I'd love for Debian to be on the latest version, but I lack the free time to work through the compile issues that each new version presents in a timely fashion.
All of this work is being done in the open so anyone is free to help out. The repo containing the Debian build files is here: pkg-llvm / swiftlang · GitLab
I have a 5.8 development branch, but I don't think I've pushed to it yet as I've been working alone and don't push builds that don't work. Anyone can clone this repo and hack away at it, just don't forget to mind Debian policies.