Add CaseIterable conformance to Platform

[Kyle-Ye]

Add CaseIterable conformance to Platform

Motivation:

Close #4478

Sometimes downstream package only cares about excluding a given platform (eg. wasi).

And each package need to maintain a supportedPlatforms array and update it when there is a platform added in SwiftPM(eg. visionOS).

We'd better fix it upstream here. And I think @neonichu's idea to add a CaseIterable conformance is great.

#4478 (comment)

Modifications:

Add CaseIterable conformance to Platform

[Kyle-Ye]

Some question here:

1. Why some new platform (eg. Platform.visionOS) is not marked with @available(_PackageDescription, introduced: 5.x) while some is marked(eg. Platform.openbsd)
2. We can't use if #available(_PackageDescription 5.2, *) currently. When a new platform is introduced on Swift 5.11 and is marked as @available(_PackageDescription, introduced: 5.11), how can I append it conditionally?

[neonichu]

1. That seems like a mistake.
2. I think we would need #available support to make this work.

[Kyle-Ye]

1. Got it. Then maybe I can add check the time when they are added and add the corresponding available mark in this PR.
2. if #avaiable(_PackageDescription 5.2, *) is currently not a valid Swift statement and a Swift Proposal for this may be needed.

[Kyle-Ye]

I've seen some usage on Swift repo with if #available(SwiftStdlib 5.3, *) maybe it is already supported upstream 🤔 and all we should do is add some flag?

[Kyle-Ye]

let availabilityDefinition = PackageDescription.SwiftSetting.unsafeFlags([
    "-Xfrontend",
    "-define-availability",
    "-Xfrontend",
    "SwiftStdlib 5.7:macOS 13.0, iOS 16.0, watchOS 9.0, tvOS 16.0",
    "-Xfrontend",
    "-define-availability",
    "-Xfrontend",
    "SwiftStdlib 5.8:macOS 13.3, iOS 16.4, watchOS 9.4, tvOS 16.4",
    "-Xfrontend",
    "-define-availability",
    "-Xfrontend",
    "SwiftStdlib 5.9:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999",
])

Found the trick here, looks like SwiftStdlib is just a typealias for the OS check.

[tomerd]

@Kyle-Ye @neonichu what are the next steps on this PR?

[neonichu]

Not sure we have a path forward without compiler changes to support #avaiable for PackageDescription availability or some other way to access the selected API level.

[Kyle-Ye]

Not sure we have a path forward without compiler changes to support #avaiable for PackageDescription availability or some other way to access the selected API level.

As @neonichu said, for the Darwin platform (eg. macOS) we can check the availability in the runtime via if #available. However such ability is currently not support for PackageDescription.

eg. SwiftUI/ControlSize on macOS platform

@available(macOS 10.15, *)
public enum ControlSize: CaseIterable {
    case mini
    case small
    @available(macOS 11, *)
    case large

    public static var allCases: [ControlSize] = {
        // ✅ Supported
        if #available(macOS 11, *) {
            return [.mini, .small, .large]
        } else {
            return [.mini, .small]
        }
    }()
}

@available(_PackageDescription, introduced: 5.5)
public enum Platform: CaseIterable {
    case iOS
    @available(_PackageDescription, introduced: 5.11)
    case visionOS

    public static var allCases: [Platform] = {
		// ❌ Not supported. 
        // PackageDescription version checks not allowed in #available(...)
        if #available(_PackageDescription 5.11, *) {
            return [.iOS, .visionOS]
        } else {
            return [.iOS]
        }
    }()
}

cc @tomerd

[tomerd]

should we then close this PR and/or open an issue asking for an enhancement request on the compiler?

[Kyle-Ye]

I'll convert it back to a draft. And could you help file an issue asking for an enhancement request on the compiler?