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.

[x4exr]

i have been so absent lately sorry guys

[Keith-Cancel]

(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.

Having used offset() when writing some lexing and parsing code. Seeing the rational behind it's naming is interesting since I always thought the name was bit a lacking.

That said, calling this just offset() would match CharIndices. I'll be honest: I don't like offset() alone with no other context. It can imply the current index of the most recently iterated element, and not the one that comes next, depending on one's mental model. I've thought offset() was a little odd for CharIndices without other context, and reading the comments there shows I'm not the only one. Although it is stabilized, I don't think it was the best name chosen.

If it were me I would have called it one of the following:

• pending_index() (I am kinda partial to this one)
• cursor()
• cursor_index()
• front_index()

offset() alone is vague; next_<anything>() can imply state is being modified. I like pending_index() because, regardless of someone's mental model of the iterator, it clearly implies the index that will be produced next.

Lastly, a peek_<...>() name implies a relationship to Peekable. So while, in a vacuum, peek_index() seems reasonable, but the standard library is not a vacuum.