Karl
June 22, 2021, 8:51pm
11
See the discussion from SE-0263. Apple will back-deploy what they feel like back-deploying. Even if there aren’t really any major technical difficulties, they still might not do it. Trying to make that process less arbitrary seems unlikely to succeed.
It’s their platform, after all. They are allowed to be arbitrary, and they will be.
The review discussion also brought up the topic of backward deployment, which spurned a broader meta discussion within the Core Team on how evolution proposals and reviews should approach the topic of backward deployment — a topic that has come up before.
Backward deployment is interesting because it is obviously an important concern for Swift developers on platforms where backward deployment is a meaningful concept (such as on macOS). However, even today not all platforms where Swift is supported share the same concerns about backward deployment of APIs in the Swift runtime or Standard Library. Further, in the fullness of time as Swift is supported on more platforms the exact policy of how additions to the Standard Library will be "backward deployed" may be particular to the platform vendor or in the way Swift is distributed on a given platform.
As a point of establishing precedent, the Core team feels that a reasonable policy that strikes a balance is that backward deployment decisions are not deciding factors in evolution discussions. However, the Core team feels it is fine — and valuable — for review discussions to talk about backward deployment and potentially factor those concerns into the proposal. Backward deployment alone, however, will not be a criteria for whether or not to accept a proposal. Ultimately, how much backward deployment of an API or runtime capability is supported is a combination of (a) what is technically possible as well as (b) up to whomever is distributing Swift on a particular platform is able to provide. Of course, some of the mechanisms that help facilitate backward deployment — such as inlining of an API — can also impact the invariants and semantics of a proposed API, and should be reviewed as part of an API proposal.
3 Likes