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 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.
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.
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.
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.
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.
A question that often arises in my head is why aren't Option and Result named Opt and Res? : )
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.
I would strongly oppose renaming the method from iter()—anything else is just too long for the amount of use iter gets.
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.
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.
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).
@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.
Yes but this is not always possible. It depends a lot on the level of granularity of the API and the particular task.
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?
