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

**URL:** <https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653>\
**Category:** Proposal Reviews\
**Created:** [December 13, 2019, 6:22pm UTC](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653 "2019-12-13T18:22:30Z")\
**Posts on this page:** 1\
**Showing post:** 73

<div class="post-metadata">

**Author:** ![dabrahams](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dabrahams/32/9815_2.png) [@dabrahams](https://forums.swift.org/u/dabrahams)\
**Post date:** [January 18, 2020, 5:51am UTC](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653/73 "2020-01-18T05:51:49Z")

</div>

> [@ben-cohen](#):
>
> > We wouldn't name an API `Array<T>.ints` just because it returns a collection of `Int` .
> 
> This is not an apt comparison, because the word "range" has more meaning in this context than the word "int". That is, when I refer to "a range within an array", it's pretty clear what I mean: the portion of the collection between two indices.

It isn't actually clear what you mean, because:

- you could be referring to a range of values in the array
- it could be an array of ranges, which is where ”a range within the array” becomes really confusing.

But more importantly, we're not even talking about an API on the collection whose indices are being stored. In fact, such a collection may not exist, because this is an API on `RangeSet`, _which has nothing to do with collections_. `RangeSet<Float>` is a really useful type all on its own (and Collections with `Float` indices are pretty rare). The same rationale—that there may not be any `Collection` involved, also argues against `subranges` for this case—which is why `contiguousSubsets` remains the best name I've seen yet.

Even if I bought into the idea that “range within a collection” was a well-understood concept, that would still make `ranges` as inappropriate a name as `indices` is for a property of `RangeSet` that is not also a `Collection` and may not even be related to any `Collection`. So perhaps my comparison could have been more apt, but making it so only hurts the case for the name `ranges`.

> [@](#):
>
> ![](https://global.discourse-cdn.com/swift/original/2X/9/9e60629128c10768200a42b2303572c53369c573.png) dabrahams:
> 
> > As I've been trying to say, we _don't_ already describe a range of positions in a collection by simply saying “range.” There's no precedent in Swift for talking about “a range of a collection” as far as I know
> 
> I disagree. People use this terminology all the time.

I'd like to see some evidence to back up that assertion, please. I've heard “range of elements in a collection” and “range of positions in a collection” but never just “range of a collection.”

> [@](#):
>
> > ```swift
> > 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"!
> 
> > ```swift
> > 
> > ```
> 
> Personally I think the word "sub" is a needless word fragment in `removeSubrange` and if it were proposed today I'd advocate stripping it. I think this example is a contrived and uncompelling argument for it. It is just not reasonable to interpret the above code as removing the first element and I don't think this would ever happen in practice.
> 
> Yes, if I have an array of ranges, then the term "range" becomes ambiguous when talking about that specific case.

You're missing the point; this is about comprehensibility of code for someone who doesn't necessarily already know what they're dealing with. If I am reading unfamiliar code, it's very likely I don't _know_ what the element type of a given collection is. When I read `x.removeRange(1..<2)`, and I don't know the standard library APIs well, and I don't know the type of `x`, what am I going to assume that code means? The obvious interpretation is that `x` is a thing that contains ranges, and I'm going to remove one.

Now you could say `removeSubrange` suggests that `x` is a thing that contains “subranges,” and that's true, but the problem is not as bad because `Subrange` is not a thing that you will have encountered in the library and may even recognize as the argument to the method. It would be reasonable to claim that `removeSubrange` does not improve the problem _enough_ to be worth the added syllable. I don't know how to judge that; by any objective measure those three characters are very small penalty to pay—but it's still always possible we could have done better; that's not really the point. The question is really whether it's worth “sweating the details” when it comes to naming.

I'm going to remind everyone [again](https://forums.swift.org/t/se-0270-add-collection-operations-on-noncontiguous-elements/30691/38), but in a different way, of how we got here. The process that resulted in [adding “sub”](https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md) to that name was the product of about a year of really hard work and thinking about how to name APIs by a group that included me, @Douglas_Gregor, @Chris_Lattner3, @Tony_Parker, and several others. Then @gribozavr, @moiseev and I worked on the specific changes, got them reviewed by the aforementioned group, and took them through an extended [review](https://forums.swift.org/t/review-se-0006-apply-api-guidelines-to-the-standard-library/1163/89) on this list. That is to say, it wasn't just me, there were principles driving these changes, a substantial group of smart people worked really hard to develop, scrutinize, and ratify them with the community, with the intention to set a precedent for how things should be done—and especially, which things _matter_ when considering naming—in the future. One of the first conclusions (actually precedented in the Cocoa guidelines) was that it's important to _have_ some principles to guide naming choices. Another important conclusion while we would _try_ to avoid names that “feel weird,” surface aesthetics take a back seat to communicating semantics and avoiding easy misinterpretations.

Now, it's no longer my job to defend the design principles of the standard library. Even if it were, I'm not in a position to stop the community if it wants to break with the precedents set in 2016. The questions are a). what are you going to replace those old principles with? and, b). are you going to change the existing names made on the old principles, or are you just going to things differently going forward?

---

_[View the full topic](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653)._