Hi everyone,
Now that Swift can ship in the OS, all new features in the standard library will need to have an availability annotation for platforms that do so, to ensure that the feature is only used when it’s available.
For example:
// in the standard library
@available(macOS 10.14, iOS 12, watchOS 5, tvOS 12, *)
func funkyNewFeature() -> Int { return 42 }
// and in user code
if #available(iOS 12, *) {
total += funkyNewFeature()
} else {
// OS too old, no new feature for you,
// implement some workaround...
total += 42
}
This presents a challenge for ongoing development of the standard library, because those OS versions do not yet exist. Even if you chose to guess in which future version number of an OS a new feature will land, you would not be able to test your new function because you will not be running that version of the OS.
To facilitate this, a special case has been added to availability checking for platforms that now ship as part of an OS release i.e. macOS, iOS, tvOS, and watchOS. When checking the version of the OS at runtime, major version 9999 will always succeed. The following will now print “I’m available!" on a compiler built from master, whereas in Swift 5.0 it will build, but fail at runtime:
@available(macOS 9999, *)
func f() { print("I'm available!") }
if #available(macOS 9999, *) {
f()
} else {
fatalError("nope")
}
When releasing a new version of the OS with the latest standard library, the platform owner will go through all newly available functions and update their availability (and any associated tests) with the appropriate real version number.
Going forward, when raising PRs against the standard library, please use this convention in new functions (including internal-but-inlinable ones) as well as when writing tests.
Thanks!
Ben