Expanding on the package managers for a moment: what is available via the Linux system package managers is determined entirely by those Linux communities. If there was a desire to have Swift in the Debian package tree, any Debian contributor can arrange to have that happen by volunteering to maintain the Debian packages.
However, based on some of the observed discussions around ABI stability, I want to make something clear. Shipping Swift in the standard system package tree will need to pin Swift to a specific compiler version on that distribution at that version. For example, consider Debian Buster, the upcoming stable Debian that will ship sometime this year. It was frozen in March, so the latest reasonable compiler version it could have packaged would have been Swift 5.0.0 (side note: that would have been bloody fast, it'd be more likely to have a 4.2 release, but I digress).
At this point, Debian Buster could never upgrade the Swift it ships past this level. This is because doing so would change the runtime copy of libSwiftCore, which would potentially break any application compiled on Buster. That's obviously unacceptable, and would not be tolerated by Debian.
Debian Buster will be the stable release for 2 years and supported for 3, meaning that for 2 years the only Swift version available on Debian would be 5.0. Nothing in 5.1 or any future release, which means no opaque result types, no function builders, nothing.
As always, it's helpful to be careful what you wish for. I think what most folks currently want is a one-click download of recent Swift snapshots appropriate for their platform. As @jonprescott made clear, this is fundamentally a resource issue that the community can address by setting up appropriate integration tools and contributing community CI.