Having a number of conversations about the design has helped me clarify the intuitive sense that led to proposed design. Leaving aside brevity and diagnostics, I think there are more fundamental arguments to consider about the role of the attributes.
There are two pieces of information that need to be conveyed when back deploying an API:
- The version of the OS the client can first use the API in
- The version of the OS when the API became ABI in the OS
While it is useful to talk about these two versions as a package when describing the proposal and its mechanics, these two versions represent very different concepts.
The versions of the OS an API may be used from is directly relevant to API clients. This information is already expressed with the existing @available
attribute. Introducing a secondary label or attribute that also describes the first OS that a back deployed API can be used from doesn't give the API client new information that is actionable. I'm thinking of this in terms of progressive disclosure; you shouldn't need to understand what "back deployment" is in order to use a back deployed API. A back deployed API has availability that works like every other API.
The version of the OS the API became ABI in is a detail that the library author needs to provide to the compiler so that the generated code can handle the absence of the ABI version. This version is not availability information; it does not by itself alter which contexts an API can be used from. The primary audiences of this information are the library maintainers and the compiler.
To sum it up, we should not introduce a second version label (or separate attribute) that Swift users need to understand as having the same effect as the introduced:
label in @available
. The version that the API became ABI in is also not the same type of information as the existing fields of @available
since it does not describe a restriction on the contexts in which the API can be used. Therefore it does not belong inside the @available
attribute. I think the design as proposed takes these considerations into account best. It introduces a single new attribute with the one new type of version necessary to achieve back deployment while leaving the existing semantics of availability unchanged.