SE-0270 (Review #2): Add Collection Operations on Noncontiguous Elements

[Nevin]

@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.