# 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:** 14
**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\ **Post date:** [December 15, 2019, 2:58am UTC](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653/14 "2019-12-15T02:58:11Z")
> [@dabrahams](#): > > Personally, I don't think it's useful to try to communicate type information in names, except where it's actually needed to prevent confusion. Semantically, an index is just a pointer to an element, and I don't think it's very useful, in most cases, to distinguish a pointer-to-thing from a thing-itself, in naming. I’m not quite sure what you’re getting at here. When you want an index, you call a method like `firstIndex(where:)` or `index(after:)`. When you want more than one index, it follows that you should call a method like `indices(where:)`. An argument could be made that `allIndices(where:)` has more symmetry with `firstIndex(where:)`, but regardless the word “indices” should be involved. > [@dabrahams](#): > > You can say, “here's a list of the names of people coming to the party,” but most of us will just say, “here's a list of the people coming to the party” without causing problems of understanding. I think this supports my point. There’s no reason to make people ask for “a bunch of ranges of indices that satisfy the predicate” when they could instead simply ask for “a bunch of indices that satisfy the predicate”. > [@dabrahams](#): > > > [@Nevin](#): > > > > Just going by the method call, `numbers.ranges(where: isEven)` could plausibly (on the surface at least) seem to return a collection of `Element` . > > Could you explain how you arrived there? I don’t see anything in that name that suggests it is returning a collection of Element. It’s more that `ranges(where:)` could be ranges of _anything_. There’s no indication that the method is at all related to indices of the collection. The other index-returning methods are named things like `firstIndex(where:)`, and for clarity and consistency we should continue that pattern. If we were to name it `ranges(where:)` then it would be clear that it has something to do with ranges, but not what kind of ranges nor what those ranges are for nor what the purpose of the method itself might be. The code becomes unclear and confusing to readers. In contrast, if we name it `indices(where:)`, then it is clear that the result is a bunch of indices, and readers of the code will immediately grok what they are for. This spelling does make it unclear how those indices are stored and what the return type is, but, if I may quote a member of the Core Team and co-author of the API Design Guidelines: > [@](#): > > I don't think it's useful to try to communicate type information in names, except where it's actually needed to prevent confusion. --- _[View the full topic](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653)._