enumerate should be generic over the integer

[vks]

Currently enumerate uses usize for counting. This is necessary when iterating over slices (probably the most common scenario). However, in general an iterator is not necessarily related to memory, so it may make more sense to use other integer types.

It seems sensible to make enumerate generic over the integer type used for counting. This is backwards compatible, so it shouldn't break existing code.

pub struct Enumerate<I, T: Int> {
    iter: I,
    count: T
}

Would it be possible to make this change although enumerate is marked as stable?

[steveklabnik]

nominating, like we've been doing for possible backompat-libs issue

[bluss]

Isn't it likely to break code where the integer type can't be inferred?

[utkarshkukreti]

A little off-topic, but doesn't (0..).zip(_) now do the exact same thing as .enumerate()? We can just zip with 0u8.. to do enumerate() with u8.

fn main() {
    for pair in "foo".chars().enumerate() {
        println!("{:?}", pair);
    }

    for pair in (0..).zip("foo".chars()) {
        println!("{:?}", pair);
    }
}

=>

(0, 'f')
(1, 'o')
(2, 'o')
(0, 'f')
(1, 'o')
(2, 'o')

[vks]

Python has both of them as well, I think it is common enough to warrant its
own iterator.

On Tue, Feb 24, 2015, 09:30 Utkarsh Kukreti notifications@github.com
wrote:

A little off-topic, but doesn't (0..).zip(_) now do the exact same thing
as .enumerate()? We can just zip with 0u8.. to do enumerate() with u8.

fn main() {
for pair in "foo".chars().enumerate() {
println!("{:?}", pair);
}

for pair in (0..).zip("foo".chars()) {
    println!("{:?}", pair);
}

}

=>

(0, 'f')
(1, 'o')
(2, 'o')
(0, 'f')
(1, 'o')
(2, 'o')

—
Reply to this email directly or view it on GitHub
#22716 (comment).

[pnkfelix]

E-needs-decision. cc @aturon 1.0 beta P-backcompat-libs.

[nikomatsakis]

Personally I'm inclined to keep things simple and just use usize here. In particular, to do otherwise would require basically adding an associated Index type to the Iterator trait, because we must have some way for generic wrappers like Map to reflect the index type of the things they are iterating over.

[nikomatsakis]

(The fact that zipping with 0.. provides an easy way to use other kinds of integers if you prefer is nice, though.)

[vks]

Then I would honestly rather remove enumerate than having a crippled version.

[bluss]

itertools already has a generic .enumerate_from(x) (which is basically the same as zipping with x..), you could possibly import that into libcore. Specifying the starting point adds another degree of customization and an obvious place to specify the integer type. For a generic .enumerate() I would worry it's too confusing and nonobvious how to specify the integer type to use.

Standard .enumerate() is not crippled just because it's simple. It's one of a million possible iterator adaptors, and not all of them are going to be included in Rust by default.