Tracking Issue for `peek_index`

[x4exr]

• ACP Adding position to Enumerate libs-team#435 (comment)
• PR add next_index to Enumerate #139533

Feature gate: #![feature(peek_index)]

This is a tracking issue for the new peek_index function on the Enumerate iterator.

Public API

let e = vec![1, 2, 3].into_iter().enumerate();
assert_eq!(e.peek_index(), 0);
e.next();
assert_eq!(e.peek_index(), 1);

Steps / History

• Created ACP issue.
• Opened pull request following the ACP approval.

Unresolved Questions

• None yet.

[GrigorenkoPV]

I suspect that the code example is slightly incorrect, as the .0 part after .peek_index() implies it returns a tuple.

Also I think a signature of the added function(s) would be a better fit than a usage example for the "Public API" section, (I'm not a team member though, so I might be wrong).

[x4exr]

That was a typo on my part lol, thanks for catching that

[jogru0]

I'll take a look at the closed PR.

@rustbot claim

[jdahlstrom]

(commencing bikeshedding…)

There's some prior art on naming: The method returning the "next" offset of CharIndices was stabilized as just offset in 1.82. Before stabilization there was quite a bit of discussion on whether the name should contain "next", but in the end dtolnay's arguments convinced the team that it shouldn't. The arguments seem to apply here too, and now there's the consistency angle as well.