Hello, Swift community.
The review of SE-0270 spanned three separate review periods, from November 11th, 2019, to January 28th, 2020. The latest round of review is here.
Community feedback was highly positive on adding this feature in some form, but many details of the design were heavily debated. Reflecting on that feedback, the authors revised the proposal several times, trimming some controversial features and renaming others. Feedback on the third review suggests that, while many community members are now satisfied with the proposal, others remain concerned with some aspects of the current design. In the opinion of the Core Team, the remaining controversies do not justify returning the proposal for further review or revision; a decision just needs to be made.
There seem to be two main points of contention:
- The proposal names its central type
RangeSet, but some community members feel thatRangeBasedSetwould be clearer, since the type is substantially different from a simple set of ranges. The Core Team feels that this is unlikely to be confusing in practice and that the extra word will not clarify anything to those who might be confused. - The proposal adds several collection methods referring to "subranges". This term can be seen as restating type information about the value it describes, which is generally undesirable; however, in this case it also describes the relationship between
selfand the value and so still provides some value. This term is also less than perfectly clear about the nature of the sub-ranges it works with: for example, they could be ranges of elements rather than indices, or the element of the underlying collection might be a range type. However, this objection applies equally to several existing methods in our collection APIs that refer to "subranges", and the Core Team does not believe it would be justifiable to rename those methods after they've been so long established; therefore the term "subranges" is a precedent that's not going anywhere, and it would be poor practice to introduce a second term with overlapping meaning just because we now find that term imperfect.
In sum, the Core Team is satisfied with the current proposal, and it is duly accepted .
Thank you to everyone who participated in this process. This review was particularly drawn-out, and I know it tested the patience of some of the participants; the Core Team will be thinking about how it can better manage reviews in the future where serious counter-proposals are developed during the review. Our goal is always to get the best change possible for the language, which may not correspond to the first proposal that makes it to the review stage. Accordingly, we think it's important for authors to take the time to respond to counter-proposals — even if just to give some reasons they disagree — and to engage in any subsequent discussion. This review featured several debates which contributed quite a lot to the result: not only did they lead to revisions, but a lot of reviewers also incorporated responses to them as part of their feedback. However, we're conscious of how draining it can be to drive an evolution proposal through pitch and review, and we know that most reviewers don't have the time to keep up with all the lengthy arguments and counter-arguments that happen in review threads. The Core Team would be very interested in suggestions for how review managers can draw attention to these debates and counter-proposals and solicit community feedback on them without excessively dragging out reviews or requiring lots of additional work from proposal authors. (That discussion should be in a new thread.)
Again, thank you for helping to make Swift a better language.
John McCall
Review Manager