Returned with the intent to accept, with request for minor revision
The proposal has been accepted, with the request that the proposal author revises the API name to include "unsafe". This was brought up during the review discussion, and the Core Team agreed this was an important aspect to include in the API's name.
The rationale is that we have a bit of a model where we use the term "unsafe" whenever an API is introducing an unsafe buffer or pointer into your code. This identifies a transition into a region of "unsafety". Once you have a value of an "unsafe" type, you don't need to keep calling the APIs that work on those values "unsafe". This is something worth formalizing more in the API guidelines.
The API author (who is currently on vacation) should propose a new name for the API, and we will extend the review for a few days to review it with the community.
Discussion on Backwards Deployment
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.
Remark on tardiness of review process for this review
I'd like to extend my appreciation to the community for the patience they've shown with the tardiness of myself as the review manager on the efficiency of how this review was run, discussed within the Core team, and circled back with the community. There are opportunities to improve the efficiency and experience of the review process, and the Core team is actively looking at ways to improve the review process in a variety of ways that improves turnaround time from the Core team and increases transparency in the review process.