SE-0270 (Review #3): Add Collection Operations on Noncontiguous Elements

[kylemacomber]

I advocated for embracing subrange in this revision of the proposal in large part because of your observation that "subrange" is the existing term of art for "a range of positions in a collection":

@dabrahams

we don't already describe a range of positions in a collection by simply saying “range”... we already have a term of art for this: “subrange.” We intentionally used that word instead of range when naming removeSubrange because it is clearer:

var rs = [1..<2, 3..<4, 5..<6]
rs.removeRange(1..<2)     // if we had made the wrong naming choice
print(rs.contains(1..<2)) // prints "true"!

A subrange is not "a range of elements in a collection":

1. Swift already has SubSequence and Slice for that.
2. If it were, removeSubrange wouldn't be any clearer than removeRange.

@dabrahams

maybe someone else can come up with a definition that makes everything consistent again

@dabrahams

let indicesOfEvens = numbers.subranges(where: { $0.isMultiple(of: 2) })

...

What is this thing the latter method is returning, semantically?

I think of "subrange" now as "a range of positions that represent consecutive elements in a collection". So numbers.subranges { $0.isMultiple(of: 2) } is returning "the positions of the elements that are a multiple of 2".

I think there's a lot of nice synergy with removeSubrange(_:) and replaceSubrange(_:with:) in naming the algorithms subranges(where:), removeSubranges(_:), and moveSubranges(_:to:). (Also I imagine we'll be adding moveSubrange(_:to:) soon, in a follow up proposal.)