# The name \`Iterator\`

**URL:** <https://internals.rust-lang.org/t/the-name-iterator/666>\
**Category:** bikeshed (deprecated)\
**Created:** [October 17, 2014, 11:42pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666 "2014-10-17T23:42:32Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![aturon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aturon/32/3272_2.png) [@aturon](https://internals.rust-lang.org/u/aturon)\
**Post date:** [October 17, 2014, 11:42pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/1 "2014-10-17T23:42:32Z")

</div>

Warning: bikeshed.

We’re a bit inconsistent presently in whether we use `Iterator` or `iter`; usually the former at the trait/type level, and the latter at the method level. For example, we have `FromIterator`, whose sole method is `from_iter`.

A [recently accepted RFC](https://github.com/rust-lang/rfcs/pull/344) proposes both to keep trait names grammatically simple and consistent with methods whenever possible.

It’s a minor point, but should we consider using `Iter`/`iter` across the board? Or `Iterator`/`iterator`? Or is today’s mix warranted as a special case?

The main argument for `Iterator` at the type/trait level is precedent/familiarity from other languages. And on the other hand, you write the method names _far_ more often, so it makes sense to have them be as short as possible. So there is some justification for today’s state of affairs.

---

<div class="post-metadata">

**Author:** ![cgaebel](https://avatars.discourse-cdn.com/v4/letter/c/da6949/32.png) [@cgaebel](https://internals.rust-lang.org/u/cgaebel)\
**Post date:** [October 18, 2014, 2:28am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/2 "2014-10-18T02:28:22Z")

</div>

I’m definitely a fan of the more concise `Iter`. It’s not easily confused with a different concept, and a very common type encountered.

---

<div class="post-metadata">

**Author:** ![Gankra](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gankra/32/6002_2.png) [@Gankra](https://internals.rust-lang.org/u/Gankra)\
**Post date:** [October 18, 2014, 5:08am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/3 "2014-10-18T05:08:15Z")

</div>

Unclear: are you also suggesting renaming Iterator/DoubledEndedIterator/etc themselves, or just related traits like FromIterator? I like being able to refer to Iterators, not “Iters”. 😕

Regardless, I’d like to note that FromIterator is _already_ sort of weird in that it’s rarely called directly, but instead called implicitly with `collect()`. It’s a wash either way in my mind, but my gut says go with `FromIter` since `iter` is generally how code talks about iterators today.

---

<div class="post-metadata">

**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/stebalien/32/228_2.png) [@stebalien](https://internals.rust-lang.org/u/stebalien)\
**Post date:** [October 18, 2014, 5:13am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/4 "2014-10-18T05:13:48Z")

</div>

Actually, I’d go the other direction and rename Map to Mapper. When you call map, you get a Mapper (an object that maps); when you call filter, you get a Filter (an object that filters), when you call iter (short for iterate) you get an Iterator. This would also remove any confusion between collections::Map and iter::Map.

---

<div class="post-metadata">

**Author:** ![abonander](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/abonander/32/1284_2.png) [@abonander](https://internals.rust-lang.org/u/abonander)\
**Post date:** [October 18, 2014, 6:51am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/5 "2014-10-18T06:51:33Z")

</div>

AFAIK, `collections::Map` is going away, as are the other collections traits.

`Mapper` just sounds weird, and it’s double the length. I prefer `Map` and `Iter`, in the same vein as `Vec` over `Vector` and `Bitv` over `Bitvector` and `bool` over `boolean` and `fn` over `function`. The conciseness really cuts down on visual noise, IMO, especially with multi-level type signatures that are common in the iterators API.

---

<div class="post-metadata">

**Author:** ![petrochenkov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/petrochenkov/32/2784_2.png) [@petrochenkov](https://internals.rust-lang.org/u/petrochenkov)\
**Post date:** [October 18, 2014, 10:02am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/6 "2014-10-18T10:02:22Z")

</div>

`Iter` is surely tempting in its conciseness.

One argument against I can thought of is potential future introduction of something like `Iterable` - a thing that can be iterated through. Then pair `Iterator/Iterable` will probably look more descriptive and less confusing than `Iter/Iterable`. But that's just speculations.

> [@abonander](#):
>
> I prefer Map and Iter, in the same vein as Vec over Vector and Bitv over Bitvector and bool over boolean and fn over function.

A question that often arises in my head is why aren't `Option` and `Result` named `Opt` and `Res`? : )

---

<div class="post-metadata">

**Author:** ![glaebhoerl](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/glaebhoerl/32/1978_2.png) [@glaebhoerl](https://internals.rust-lang.org/u/glaebhoerl)\
**Post date:** [October 18, 2014, 12:23pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/7 "2014-10-18T12:23:52Z")

</div>

As I wrote on that thread I think the logical convention would be that `Iterator` stays `Iterator`, and `Iterable` is instead called `Iter`. Currently methods which return an iterator are called `iter()`. An iterable trait would abstract this functionality, and presumably have a single method called `iter()`. It then makes sense to follow the trait-name-follows-method-name convention and also call the trait `Iter`.

---

<div class="post-metadata">

**Author:** ![aturon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aturon/32/3272_2.png) [@aturon](https://internals.rust-lang.org/u/aturon)\
**Post date:** [October 18, 2014, 9:44pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/8 "2014-10-18T21:44:08Z")

</div>

@glaebhoerl That’s a great point; I think the comment on the other thread hadn’t quite sunk in.

---

<div class="post-metadata">

**Author:** ![nightpool](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nightpool/32/1040_2.png) [@nightpool](https://internals.rust-lang.org/u/nightpool)\
**Post date:** [October 19, 2014, 6:28pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/9 "2014-10-19T18:28:34Z")

</div>

1. I would strongly oppose renaming the method from `iter()`—anything else is just too long for the amount of use iter gets.
2. I get the reasoning behind `Iterable` =\> `Iter`, but I don’t think it’s a good idea in the long run. Personally, I would prefer the longer, more explicit trait names, with the shorter function names. You get the benefits of it being self-documenting, because its the only method in that trait, as well as the benefits of the shorter method names.

---

<div class="post-metadata">

**Author:** ![strcat](https://avatars.discourse-cdn.com/v4/letter/s/4da419/32.png) [@strcat](https://internals.rust-lang.org/u/strcat)\
**Post date:** [October 21, 2014, 1:27am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/10 "2014-10-21T01:27:13Z")

</div>

The method is the short form of _iterate_, not _iterator_. I don’t see a problem with using `Iter` for the trait name. It’s just as easy to understand so it might as well be shorter.

---

<div class="post-metadata">

**Author:** ![fread2281](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/fread2281/32/326_2.png) [@fread2281](https://internals.rust-lang.org/u/fread2281)\
**Post date:** [October 23, 2014, 12:28am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/11 "2014-10-23T00:28:13Z")

</div>

IMO, having a trait named `Iter` is a bad idea because once we have `Iterable` there will be multiple things it could stand for.

---

<div class="post-metadata">

**Author:** ![darinmorrison](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/darinmorrison/32/13361_2.png) [@darinmorrison](https://internals.rust-lang.org/u/darinmorrison)\
**Post date:** [October 29, 2014, 12:29pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/12 "2014-10-29T12:29:22Z")

</div>

I also favor longer names for traits/types and shorter names for methods. I think the current approach is warranted. The idea is that the _type_ is the most important part information wise. If that is clear, shorter method names are fine. In fact, they’re a good thing. In my opinion, too much redundancy (Iterator/iterator) leads to unnecessarily verbose and cluttered code (e.g., Java).

---

<div class="post-metadata">

**Author:** ![darinmorrison](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/darinmorrison/32/13361_2.png) [@darinmorrison](https://internals.rust-lang.org/u/darinmorrison)\
**Post date:** [November 4, 2014, 3:22pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/14 "2014-11-04T15:22:41Z")

</div>

@yigal100 it’s more than that—the choice to use longer names (not just whether they’re repeated unnecessarily due to lack of type inference) has a negative impact on readability I think. When you’re trying to read or write an algorithm, you really don’t need to spell out `iterator` each time when something like `it` or `.iter()` suffices for reference. If you need to write these multiple times in the same function or method or if you’re chaining several methods together, the longer names are not adding anything. It’s not about the number of keystrokes.

Longer type names are fine and usually a good thing. Method names shouldn’t need to be longer just to preserve some sort of symmetry though.

---

<div class="post-metadata">

**Author:** ![darinmorrison](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/darinmorrison/32/13361_2.png) [@darinmorrison](https://internals.rust-lang.org/u/darinmorrison)\
**Post date:** [November 4, 2014, 7:42pm UTC](https://internals.rust-lang.org/t/the-name-iterator/666/16 "2014-11-04T19:42:07Z")

</div>

> [@anon32976453](#):
>
> If you find yourself repeating the same name over and over again while using some API, it is a code smell that demonstrates bad API design where better abstraction should have been used.

Yes but this is not always possible. It depends a lot on the level of granularity of the API and the particular task.

> [@anon32976453](#):
>
> In the context of Rust, I'd argue that we should be extra careful naming methods because types are usually inferred and so the only context for human readability is the method name. For example: let it = something.to\_iter(); "it" is abbreviated because it's local to a small context. Inference hides the descriptive type name "Iterator" and the method is also abbreviated so the readability of this line is harmed. Is "it" an iterator or maybe an Iterable?

I understand the motivation there but I think it gives a false sense of readability. For example, when I see a method named `.some_intuitive_name`, I still feel the need to look up the type of the method to ensure that I understand what the code is doing. So once I've gone and done that and I have the type in mind, do I need to see it spelled out in full every single time?

And to the point about IDEs, if we have those and we have local type inference, that means we should be able to hover over methods and get the type, so again what's the value in having longer names?

---

<div class="post-metadata">

**Author:** ![aturon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aturon/32/3272_2.png) [@aturon](https://internals.rust-lang.org/u/aturon)\
**Post date:** [March 25, 2019, 8:23am UTC](https://internals.rust-lang.org/t/the-name-iterator/666/17 "2019-03-25T08:23:00Z")

</div>

Closed on March 25, 2019, 8:23am UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
