Add Iterator::enumerate_from(self, first: usize)

[SimonSapin]

There is precedent for an optional first/start parameter in Python: https://docs.python.org/3/library/functions.html#enumerate

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dtolnay (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[bluss]

This is covered by std by using zip with a range, (from..) as the range in this case. Zip with range is flexible about index type too.

Just so that we have existing solutions to compare with.

[dtolnay]

+1 for zip. In the code in the example I would write (1..).zip(&a) instead of a.iter().enumerate_from(1).

[kennytm]

Perhaps we should instead modify the doc to mention .zip can also be used for (1..).zip(this), in additional to enumerating with a different integer type.

[Havvy]

The documentation can certainly be added to zip, but that's also an argument against having enumerate itself too, since you can just zip 0.. to get the same behaviour.

[kennytm]

I consider enumerate as an exception since it has been grandfathered in from 0.7 (#5927), and also referring to the index of an element is a much more common use case.

[cuviper]

Enumerate is conditionally double-ended, so you'd need to zip with 0..len to get equivalent behavior. While you could use len = usize::MAX, next_back() will take forever to walk that back.

Also, Enumerate has optimized fold and a few others, but Zip can't have the same in general. (But it could be specialized for a Range part.)

[cuviper]

As to this PR, note that Enumerate::next_back assumes that self.count + len won't overflow, but that's not true if you can have an arbitrary starting point.
e.g. (0..10).enumerate_from(usize::MAX).next_back()

[carols10cents]

So what is the status of this PR @dtolnay? Are there modifications that are needed or is it ready to r+?

[dtolnay]

I would prefer to see an RFC written for this, to motivate a little better and explore the alternatives. Some things to consider:

• How this compares with (n..).zip(iter). There is some justification for why enumerate_from is better in Add Iterator::enumerate_from(self, first: usize) #45833 (comment).

• How this compares with iter.enumerate().map(|(i, v)| (n + i, v)) which solves the conditionally double-ended problem and optimized fold.

• Implications of overflow, which Enumerate::next_back can assume never happens Add Iterator::enumerate_from(self, first: usize) #45833 (comment). I think this is covered by the disclaimer under "overflow behavior" in the method doc.

• Whether it is okay to tie the return type to be the same struct type between enumerate and enumerate_from.

• Use cases, beyond just that the equivalent exists in Python.

[SimonSapin]

The space of possible solutions turns out to be larger than I thought, so asking to go through the RFC process sounds reasonable.

Use cases are mostly with start == 1, either for numbering eventually shown to humans (who tend to prefer "1" indicating the first item of a collection rather than the second), or for interfacing with systems where indices are 1-based.

I had not thought of using (n..).zip(…), it works well enough for me that I don’t feel the need to carry an RFC. Thanks for the feedback everyone.