SE-0270: Add Collection Operations on Noncontiguous Elements

[CTMacUser (Daryle Walker)]

@QuinceyMorris

Please, let's not make the mistake of calling this RangeSet , as if it somehow exhausts all future possibilities for things that have range and/or set semantics. Let's either go more specific ( CollectionIndexRangeSet or IndexRangeSet or something), or re-use IndexSet for this and rename the current IndexSet to something else (yeah, right, I know that's not gonna happen).

Unlike how we use the term, a subsequence is a not-necessarily contiguous, but still in-order, subset of elements. What we call a SubSequence is a substring under that article's philosophy. (And the "substring" term applies to any sequence-set, not just a String or other sequence of characters.) Maybe we could use "DiscontiguousIndices," or "SomeIndices"?

@QuinceyMorris

Note that I'm not objecting to the implementation actually using ranges to optimize the set of indexes, and I'm not objecting to the possibility of enumerating indexes as a set of ranges, but it seems wrongly limiting to build this into the APIs as the only and paradigm mechanisms for accessing sets of elements.

We could make a lazy version of indices(where:), but the implementation wouldn't be that different from RangeSet (or whatever we rename it), so I'm not sure it's worth it.

@QuinceyMorris

I don't think I see anything in the proposal about the invalidation of RangeSet s when the underlying collection is mutated (or when … what?). At the very least, I think the proposal should at least state the relationship between the integrity of the RangeSet vs. the integrity of the Collection .

I didn't see it either. But it should be the same as Index; a generated index value is valid until a RangeReplaceableCollection method is applied to the source collection (even if that operation's target doesn't specifically include your retained index).