Next() for iterating for a non-Iterator

help
1

I have an object that acts as an iterator, but for borrow-checker reasons it doesn't actually implement Iterator. Instead it implements a next() that has the same signature as Iterator::next().

I got some push-back on this, with two arguments: 1) If it looks like Iterator::next() it should be Iterator::next() (Because it could/should support things like rev(), map(), etc, where applicable (in this specific case I think it's unrealistic that these iterator utility functions will be used, but I still can understand the argument)). 2) Apparently there's at least one somewhat large crate that accepted this argument and renamed their next() to something else to avoid confusion.

What's the community's position (if there is one) on this? Should non-Iterator, but iterator-like, objects avoid using next() to iterate?

2

I would. I'd make it next_noun. For example, next_record might return Option<Record>.

3

If next() is the most obvious name for what you're doing then I'd stick with it.

I personally find the "If it looks like Iterator::next() it should be Iterator::next()" argument pretty weak. There are no absolutes when it comes to how you write code and name things - it all depends on context. If your non-iterator iterator can't implement the Iterator trait because of technical reasons (e.g. Iterator doesn't work with lending iterators) that doesn't make it any less of an iterator.

If you wanted, you could even implement the lending_iterator::LendingIterator trait and have an inherent next() method which just delegates to <Self as lending_iterator::LendingIterator>::next() (so people don't need to import LendingIterator themselves). That'd stop all the naysayers because you are now implementing the right trait for the job while also giving people access to nice things like map(), rev(), and so on.

10 Likes