Motivation
In Android, new API is guarded by API level. For instance, timespec_get() was introduced with Android API level 29. API level can be determined by checking the value of __ANDROID_API__ defined in the system header <android/api-level.h>.
This value is not visible to Swift, meaning that code that is conditionally dependent on the availability of some API needs to check for it (and provide a fallback path!) in C or C++ rather than in Swift.
Proposed solution
I propose we teach the compiler, when targetting Android, to expose the API level similar to how the Swift language mode and compiler version are exposed:
var ts = timespec()
#if _apiLevel(>=29)
timespec_get(&ts, TIME_UTC)
#else
clock_gettime(CLOCK_REALTIME, &ts)
#endif
return ts
Alternatives considered
- Exposing the API level as a macro would result in it being evaluated too late and the compiler wouldn't be able to ignore the API usage.
- Exposing the API level as the de facto OS version (
#available(Android 29, *)) would have a similar problem.
- "Just do it in C" is generally not the solution we want for Swift projects.
Additional information
No response
Motivation
In Android, new API is guarded by API level. For instance,
timespec_get()was introduced with Android API level 29. API level can be determined by checking the value of__ANDROID_API__defined in the system header<android/api-level.h>.This value is not visible to Swift, meaning that code that is conditionally dependent on the availability of some API needs to check for it (and provide a fallback path!) in C or C++ rather than in Swift.
Proposed solution
I propose we teach the compiler, when targetting Android, to expose the API level similar to how the Swift language mode and compiler version are exposed:
Alternatives considered
#available(Android 29, *)) would have a similar problem.Additional information
No response