The Iterator method naming, usually each_<object>, doesn’t make it obvious that an iterator will be returned.
Even worse, we can confuse them with the block-yielding variants, for example String#each_char and String#each_line.
I propose <object>_iterator, or if too long, iter_<object>, for methods returning an Iterator, instead of each_*, which is widely used for methods yielding a block.
How do you confuse yielding methods with non-yielding ones?
Both methods iterate over each element of the collection. They’re just two variants of the same behaviour. One just iterates immediately, the other detached.
Sharing the same general behaviour concludes using the same name.
Sometimes I did just have "abc".each_char after removing the block, and was confused why it can even be compiled, because a block was missing.
Then I realized that each_* methods are not only a convention for methods yielding a block, but also for iterators.
It would be better to make it obvious directly in the name that it is an iterator.
Also, being able to do "abc".each_char.each is even weirder.
Ruby has this convention where an iterator without a block returns an Enumerator object. What’s really cool about this is being able to chain iterators, which I think would be a future goal in crystal as well. (Can crystal do any iterator chaining at all yet?)
It works the same way in Crystal. The difference is that Ruby can’t chain Iterator methods but Crystal can.
Care to provide an example?
Or maybe explain what you mean by chaining.