[Pitch] Swift runtime availability

Evolution Pitches
1

Hey folks,

I've written a pitch related to extending Swift's availability checking to accommodate an ABI stable Swift runtime on non-Apple platforms. Here's a snippet from the Motivation section:

In the future, Swift could become ABI stable on non-Apple platforms. For a given platform, the Swift runtime might either be distributed with the operating system, as it is on macOS, or it could be distributed separately using some mechanism like a package manager. In the former case, extending the Swift compiler to add platform-specific availability for that operating system would be sufficient to allow developers to back deploy Swift binaries. When the Swift runtime is distributed separately from the operating system, though, a platform independent notion of Swift runtime availability is needed instead. This proposal introduces the platform independent Swift availability domain to satisfy both use cases and make the task of writing cross platform code simpler.

I'd love your feedback on this proposal. I'm especially interested in hearing about design challenges or potential issues that maintainers of cross platform packages might face. Thanks for reading!

7 Likes
2

Overall, big +1 from me. This is going to make writing availability annotations a lot easier.

Could the proposal spell out the impact on the DocC generated availability? In particular, DocC is currently only showing the availability on ABI stable platforms when an API got introduced; however, for folks using Swift on non-ABI stable platforms they need to know which Swift version an API got introduced. Is this new Swift availability visible in the symbol graph so that DocC could leverage this? cc @ronnqvist

Code may be built with an implicit minimum Swift runtime version by specifying the -min-swift-runtime-version compiler flag. This effectively supplies the compiler with a "deployment target" in terms of the Swift runtime version:

Could the proposal include a section about how this relates to the minimum platform versions in the Package.swift manifest? Should we be able to spell those minimum platform versions with Swift runtime versions instead?

4 Likes
3

Interesting pitch, wonder what the use case is though. Given that Swift is only "ABI stable on Apple's operating systems" and " When compiling for targets that do not offer an ABI stable Swift runtime, Swift availability constraints will be ignored by the compiler," plus " On platforms like macOS where the Swift runtime ships built-in, platform availability can be inferred from Swift availability," it seems like nobody will be able to use this new feature to distinguish anything different, at least as the platforms stand today.

Is the idea that initial users will build the Swift runtimes themselves, say on linux servers, and patch the stdlib source to enable this feature for non-ABI-stable platforms too? Or are there any plans to stabilize the Swift on linux ABI on some distros in the coming year?

Just wondering what concrete future use cases you're anticipating, given that it doesn't seem like this feature will do anything different today.

1 Like
4

I came to ask the same thing. Or, rather, I'd be so bold and answer "yes, we should be able to spell that".

I'd argue that for the vast majority of "general purpose" packages the platforms section is really not great in its current form. Nobody cares about the various version numbers of say tvOS, and it is all about the swift runtime + libs version compatibility.

let package = Package(
    name: "my-fantastic-package",
    platforms: [
        .swiftRuntime(.v6_3) //or maybe .swift(.v6_3)
    ],
    products: [...]
)

Are there any reasons to not "just" include the SwiftPM work in this proposal?

5 Likes
5

Swift Testing needs to mark symbols available based on compiler version rather than runtime version. Is there a way to specify that here? If not, can we make sure it's added? Thanks!

3 Likes
6

In general I think it's good, but I can see people using this just to simplify gating an Apple-specific functionality that is actually not related to Swift runtime, which makes the code looks somewhat more cross-platform than it actually is, and maybe confusing to newcomers. It's inevitable, but I think it might be a good idea to explicitly discourage this in the doc. (To be clear, the example in pitch is a cross platform Foundation feature and is IMO a perfect usecase.)

As a sidenote, now that Apple aligned OS versions, it might also be a good chance to have a unified appleOS availability domain, thus encouraging people to not abuse this Swift runtime version check. Since it's Apple specific I'm not sure if it's something pitch-able on Swift Evolution though.

2 Likes