Suggest using a range iterator instead of casting `enumerate()`

[kpreid]

What it does

Iterator::enumerate() is not the only way to produce an ascending sequence of indices; (0..) does as well, and can be combined with zip() to get the same output of pairs. This can be useful when an index of a type other than usize is needed. The lint should suggest using (0..).zip(iter) over iter.enumerate() in cases where the index produced by enumerate() is immediately converted to another type which implements core::iter::Step.

Advantage

• Simpler code.
• Avoids creating a value of the wrong type before the correct type.
• Avoids introducing a variable or repeated code if the typed index needs to be used more than once.

Drawbacks

• Could be considered to hide the possibility of overflow, though neither version is correct in that case.
• enumerate() is a familiar operation, and so zip()ping an unbounded range may be less obvious.

Example

pub fn example1(data: &mut [Vec<u8>]) {
    for (i, v) in data.iter_mut().enumerate() {
        v.push(i as u8);
    }
}

Could be written as:

pub fn example2(data: &mut [Vec<u8>]) {
    for (i, v) in (0..).zip(data.iter_mut()) {
        v.push(i);
    }
}

[riking]

This does not have the same behavior on overflow:

fn main() {
    let mut data = vec![vec![2u8; 2]; 300];
    
    example2(&mut data);
}

thread 'main' panicked at /playground/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/iter/range.rs:426:1:
attempt to add with overflow

[kpreid]

Yes, but that is arguably a benefit; it catches the generation of incorrect data (with debug assertions) where example1 does not at all. I take your point that the behavior is not identical, though.