Hi all,
The second review of SE-0376: Function back deployment ran from November 28 through December 12 and is now concluded. The language workgroup has decided to return the proposal for revision.
The core behavior of the proposal was not really disputed in this review, with the discussion mainly centered on two different aspects: the name of the attribute (along with its argument label) and the requirement that @backDeployed
also requires an explicit @available
annotation.
Attribute name
During the review, members of the community pushed back against the proposed renaming of the argument label from before:
in the first revision of the proposal to upTo:
in the second revision, citing that its not-totally-consistent existing use in the standard library doesn't justify the more awkward phrasing it implies.
Different reviewers indicated that both before:
and upTo:
was the construction that really helped them understand what the feature was doing, and that the alternative phrasing was confusing.
The language workgroup was not convinced that the proposal had settled on the best name for this feature given the objections raised, and was unable to come to a consensus about whether before:
, upTo:
, or something else entirely would properly communicate what this feature did.
The workgroup was intrigued by the idea that some of the understanding difficulty here may stem from the 'polarity' with which the name @backDeployed
describes the feature, i.e., as a backward-looking feature describing what happens on platform versions prior to the implementing version, rather than trying to more directly express the forward-looking condition. The workgroup does not necessarily endorse the @abi
spelling suggested in the linked post, but would like to see further discussion on this front to explore whether flipping the 'polarity' might make this feature more understandable.
Thus, the language work group requests that the proposal reconsider the naming for both the argument label and the base attribute in light of the points raised during review and revise the proposal with additional justification as to why the ultimately chosen name was picked over the other alternatives.
Requiring @available
Discussion on this point was relatively brief. It was pointed out that it is perfectly reasonable to back-deploy a function indefinitely, so the requirement that all functions marked with @backDeployed
also be marked with @available
explicitly is not strictly necessary.
The language workgroup feels that while it may be a noble goal to try to solve the problem of authors of ABI-stable libraries forgetting to add @available
annotations, this proposal is not the right vehicle to solve this problem. Relatedly, the workgroup does not feel that the introduction of the @backDeployed
attribute would exacerbate any of the existing difficulties in this area.
Therefore, on this front, the language workgroup requests the proposal be revised to drop the requirement functions marked with @backDeployed
also be marked with @available
.
Once any necessary further discussion concludes and the proposal has been revised, the language workgroup will run another review.
Thank you for participating in Swift evolution.
Freddy Kellison-Linn
Review Manager