Pitch: Add RangeSet and Related Collection Operations

[CTMacUser (Daryle Walker)]

@nnnnnnnn

Access elements via RangeSet

When you have a RangeSet describing a group of indices for a collection, you can access those elements via a new subscript. This new subscript returns a new IndexingCollection type, which couples the collection and range set to provide access.

Can you mutate the original collection through an IndexingCollection, like we can through a SubSequence?

@nnnnnnnn

Move elements

Within a mutable collection, you can move the elements represented by a range set, and insert them at a new index. This proposal also adds convenience methods for moving a single range or range expression, a single element, or the elements matching a predicate.

What happens if the destination index is part of the moved set? For the single-element and contiguous-range versions, I'm guessing a no-op. But what happens for discontinuous move sets?

@nnnnnnnn

Rotate and Partition

Finally, the proposal adds MutableCollection methods for rotation and half- and fully-stable partition. The partitioning methods use similar naming to the standard library's existing partition(by:) method.

These methods don't use RangeSet (externally); are they still related to RangeSet, or did you add them just for the heck of it? If the latter, maybe they could go into a separate pitch.

(Rotation has been brought up at least twice before.)

For the second and third methods, "partition" is used as a verb, not a noun. So the modifier should be "stably." I'm still trying to figure out how to incorporate the "half" in the second method. Maybe use "partitionWithStablePrefix"?

---

@Wildchild9

Also, I am curious as to your rationale for why move should be inserting elements before the specified index rather than just such index.

Those are the same thing. If the moved elements go on top of the specified destination index, the target element would move forward; that's equivalent to them going before the target element.

@Wildchild9

1.

@nnnnnnnn

public struct Elements: Sequence, Collection, BidirectionalCollection {

Though this is not wrong per say, you only need to state conformance of Elements to BidirectionalCollection as BidirectionalCollection already inherits from both Sequence and Collection .

Sometimes while implementing a type, you have to include all of the base protocols; protocol base implication does not work. Maybe that happened to the author.

---

@salutis

The pitch introduces stablePartition (mutating) and stablyPartitioned (non-mutating); perhaps it would be a good idea to unify these (stable/stably) terms somehow.

Otherwise, this an excellent proposal and I cannot wait to use these APIs.

"stably" is the adverb form of "stable," so the method pair's names are already unified. The term change in the modifier is to match the one in the main word ("partitioned"/"partition").