Adding position to Enumerate

[x4exr]

Proposal

Adding position function to Enumerate struct.

Problem statement

Other than doing next() which will progress the position, there is no straight forward way to get the position. If you call something that uses your iterator, you cant know how far it progressed without knowing the position start and end.

Motivating examples or use cases

Solution sketch

    #[inline]
    pub fn position(&self) -> usize {
        self.count
    }

Alternatives

Putting Peek around Enumerate, then doing .peek() and subtracting 1 from the position. The issue with this is if you are at the end of the iteration, you get None and need to store the end position else where. This also uses peek in a way that is unnatural and unneccesary. Its over complicated

Links and related work

• Add position to Enumerate rust#129784 Is a pull request I opened for this

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[pitaj]

The name conflicts with Iterator::position. count also won't work.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dfb1461dad8991aeeb1fb10b8187cc42

[scottmcm]

cc the IRLO thread, which has some good comments: https://internals.rust-lang.org/t/rust-lacks-enumerated-position-to-get-the-current-count/21449/7?u=scottmcm

[x4exr]

So could offset also get added to enumerated then

[workingjubilee]

Putting Peek around Enumerate, then doing .peek() and subtracting 1 from the position. The issue with this is if you are at the end of the iteration, you get None and need to store the end position else where. This also uses peek in a way that is unnatural and unneccesary. Its over complicated

You would have to subtract 1 anyways, because the initial position will actually be an item you haven't iterated to yet.

[workingjubilee]

@x4exr Do you have a practical use-case in mind? It's not entirely clear if you want what you say you want, because of the whole "the actual first position will be 0, even before you call .next()" problem.

[x4exr]

Yes I need this method to measure the number of iterations made when I call a function such as parse string with Mt iterator inside

[workingjubilee]

Ah, so you're going to call... hm, it can't be position, and it can't be count, so let's say iter.current_count() (or .offset() maybe), and then you're going to call it again later, and subtract the two? So kind of like this?

let start = iter.current_count();
my_parser_that_accepts_iterators(iter);
let end = iter.current_count();
let iterations = end - start;

[x4exr]

Yes, I was even thinking enumerated_position

[pitaj]

Another option that avoids the conflicts entirely, meaning you can use any name you want:

    #[inline]
    pub fn count(this: &Self) -> usize {
        this.count
    }

[x4exr]

why call it this? is it so rust does not accept this as a method? Also .count() already is a function in Iterator

[pitaj]

Yes, it doesn't become a method, so there's no name conflict. It's called like Enumerate::count(&instance)

[Amanieu]

We discussed this in the libs-api meeting and are happy to accept this. However we feel that the name next_index is clearer since it describes exactly what this method is returning: the index that will be associated with the next element returned by next.

[kennytm]

While next_index() is very clear on its own, together with other existing iterator functions like next() / next_back() / next_chunk() / next_if() it sounds like calling it will mutate the iterator.

[pitaj]

What about peek_index?

[x4exr]

What does it have to do with peek?

[cuviper]

It's a preview of what next() would return, similar to Peekable::peek().

[Amanieu]

While next_index() is very clear on its own, together with other existing iterator functions like next() / next_back() / next_chunk() / next_if() it sounds like calling it will mutate the iterator.

We did discuss this issue in the meeting but we felt like this was unlikely to be an issue in practice. While it follows the same pattern as the next_* methods, it's unlikely that this would be confused with advancing the iterator. The documentation would make that clear, especially with the method taking &self.

[workingjubilee]

We'll have plenty of time to argue over what Pantone chips to use, let's just get it on nightly.