# SE-0270 (Review #2): Add Collection Operations on Noncontiguous Elements **URL:** \ **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:** 46
**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\ **Post date:** [December 19, 2019, 6:06pm UTC](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653/46 "2019-12-19T18:06:07Z")
This might not be a huge proposal, but imho the topic itself is - I think even two reviews aren't enough to discuss all implications. I'm not saying we need more review cycles, though: Imho this is a perfect candidate for [SE-0264 (review #2) — Standard Library Preview Package](https://forums.swift.org/t/se-0264-review-2-standard-library-preview-package/31288)... I agree with @bzamayo that it's odd to talk about ranges all the time, while the real code is actually focused on single indices. Take `Collection.range(at:)` as an example - this could as well have an additional `length` parameter, which imho would also make it significantly more useful in other contexts besides this proposal. Another interesting example is `public func ranges(of element: Element) -> RangeSet`. The natural result of this operation is a set of indexes, and using ranges here looks like an (possible) optimization which leaks out. On the other hand, there is a very similar functionality which naturally produces ranges, and which I consider to be a big gap in Swift: We have [Apple Developer Documentation](https://developer.apple.com/documentation/foundation/nsstring/1412937-replacingoccurrences), but that's only part of `NSString`, not `String`. Therefor, I'm puzzled that something like ` public func ranges(of subsequence: C) -> RangeSet` isn't even mentioned as a possible next step. In the long run, I even see some overlap with [[Prototype] Protocol-powered generic trimming, searching, splitting,](https://forums.swift.org/t/prototype-protocol-powered-generic-trimming-searching-splitting/29415), but I no idea how well the two concepts could work together. My bottom line: Improving the ease of use of collections is a crucial topic, and I really doubt that old procedure with small, simple steps will produce great results. Instead, I'd prefer a preview package with a complete vision of how to work with `Collection` - or even several competing approaches, so that we can compare the pros and cons. --- _[View the full topic](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653)._