The fourth review of SE-0270: Add
Collection operations on noncontiguous elements ran from December 6th through the 18th. This review was both a re-review of the old proposal as part of accepting it into the standard library and a de novo review of several small revisions to the proposal, which were described in the review announcement.
Feedback during the review centered on two issues, which the Language Steering Group discussed while considering the proposal.
The first issue is whether
RangeSet is an appropriate addition to the standard library.
RangeSet is unquestionably a specialized data structure with much narrower applicability than, say,
Dictionary. The LSG has generally resisted adding data structures like this to the standard library, and we would likely not make an exception for
RangeSet as a standalone addition. However,
RangeSet is not a standalone addition; it is part of a proposal to add a number of algorithms on noncontiguous collection elements. These algorithms are best expressed in the standard library, and they need to be expressed using a type like
RangeSet in order to avoid various inefficiencies. In that context, the LSG feels it makes more sense to accept a specialized collection like
RangeSet to the standard library than to accept a less efficient API.
The second issue is the naming of various APIs, particularly
RangeSet and the
indices methods that produce
RangeSets of indices from collections. Some reviewers felt this was inconsistent and argued for different names for one or the other. The LSG is satisfied with the names in the proposal.
RangeSet is a general data structure; as discussed above, it has relatively narrow applicability, but it is broader than just sets of collection indices, and the LSG feels that it ought to have a name befitting that generality. Similarly, the LSG thinks it's fine for method names like
indices(of:) to not convey that they return a
RangeSet specifically; a
RangeSet<IndexType> conceptually represents a set of indices, which matches the method name perfectly well.
Accordingly, SE-0270 has been accepted.
I'd like to thank everyone who participated in this review, both this iteration and all the prior rounds. Your contributions help to make Swift a better language.