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.

[alexcrichton]

I personally see enumerate as a common iterator adaptor which is expected in a library of iterators, so I would not want to remove it in favor of the less intuitive foo.zip(0..). I think it's fine to have the open ended range to count with an arbitrary integer, but I don't think we need to change enumerate as-is.

[vks]

Well, then let's at least mention zip(0..) in enumerate's documentation
as the more flexible variant.

On Thu, Mar 19, 2015, 04:03 Alex Crichton notifications@github.com wrote:

I personally see enumerate as a common iterator adaptor which is expected
in a library of iterators, so I would not want to remove it in favor of the
less intuitive foo.zip(0..). I think it's fine to have the open ended
range to count with an arbitrary integer, but I don't think we need to
change enumerate as-is.

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

[alexcrichton]

Ok after some more discussion the conclusion is that we probably don't want to make enumerate generic over integer types due to worries about inference and overcomplexity. This does seems like a worthwhile A-docs bug though, so I'm going to apply that label to ensure that we mention the zip alternative in the docs.

[alexcrichton]

triage: P-high ()