Note that the syntax is:
if #available(Android 24, *) {
…
}
because this is checked at runtime, not at compile time. Is there a way to know the current SDK level at runtime?
Even then, that would not cover your use case, I believe, which is to avoid linkage entirely if your SDK target is too low. The way Darwin does it requires platform assistance and a bit of a compiler tweak, so our only option is to dlopen(), I believe — I do not think that a desirable end state would be that every Android developer compiles their Swift stack from scratch, even if it is the reality now, and any design choices that freeze us to that state of affairs look unpalatable to me.
The way s-c-f handles platform differences is by using the existing API surface wherever possible to return partial answers or appropriate errors if the relevant facilities are not available. In this case, the correct way to handle the exemplary patch would be:
- check if the relevant API is there at runtime
- invoke it if present
- behave as NSHost does when an unresolvable address or host name is used if not
If the latter would fatalError, I’m open to figuring out experimental API that applies to Android only, but that’s basically a last resort.
Edited to add: Note if 'Android' is available as a platform identifier with the full @available/if #available featureset, it is perfectly fine to mark Host as @available(Android 24, *) to signal at compile time that you need to do a runtime check before use. It still has no bearing on linkage, or on the non-goal of different Swift runtimes for different Android SDK levels.