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.
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.”
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, but in a different way, of how we got here. The process that resulted in adding “sub” 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 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?