New lint: slice.iter().next() can be replaced with slice.get()

[lights0123]

As I saw in this code review, someone wrote:

while Some(&instructions[i]) == instructions[i + acc..].iter().next() {
    acc += 1;
}

That should be replaced with:

while Some(&instructions[i]) == instructions.get(i + acc) {
    acc += 1;
}

In general, slice[i..].iter().next() can be replaced with slice.get(i), or 0 if there is no slicing done.

[esamudera]

Hello, I'm still new to open source development and I'm interested in working on this issue.

What I understand from reading the description:

• search all the iter().next()s
• determine if it's a slice between an index and the end index
• simplify the code using get(start_index)
• if it's not a slice, then just replace it with array.get(0)

Is this correct? If yes, I can start working on this.

Thank you!

[lights0123]

@esamudera Yep. You might want to handle things that Deref to a slice and implement Iterator, like Vec. However, you may want to hardcode just Vec specifically because it's possible to have a type that converts to a slice but doesn't have the same implementation for the iterator. You can also do Option.

For .into_iter(), we can probably just rely on rustc's array_into_iter/clippy::into_iter_on_ref lint.

Here's a sample test case:

fn main() {
    let s = [1, 2, 3];
    let v = vec![1, 2, 3];
    let o = Some(5);
    
    s.iter().next();
    // Should be replaced by s.first()
    
    s.into_iter().next();
    // Probaby can rely on the default `array_into_iter`/`clippy::into_iter_on_ref` lint
    
    s[1..].iter().next();
    // Should be replaced by s.get(1)
    
    s[1..].into_iter().next();
    // Probaby can rely on the default `clippy::into_iter_on_ref` lint
    
    v[1..].iter().next();
    // Should be replaced by v.get(1)
    
    v[1..].into_iter().next();
    // Probaby can rely on the default `clippy::into_iter_on_ref` lint
    
    v.iter().next();
    // Should be replaced by v.first()
    
    v.into_iter().next();
    // Tricky one—I don't think there's any other (short) way to say this (take ownership of first value)
    // So this should probably not get any warnings
    
    o.iter().next();
    // Replace with o.as_ref()
    
    o.into_iter().next();
    // Replace with o
}

[esamudera]

Okay, thank you for the additional contexts, I will start by making a new clippy_lint struct and see where it goes from there :)

[alex-700]

Hi, guys! I think this idea should be split into two lints.

• slice.iter().next() should be replaced with slice.first(). It can be done easily with adding a case to this match .

• slice[a..b].first() should be replaced with slice.get(a)

Also the second one can be improved with handling such cases like slice[a..b].get(x) and slice[a..b].last()

[esamudera]

Thanks @alex-700, I didn't know that https://github.com/rust-lang/rust-clippy/blob/master/clippy_lints/src/methods/mod.rs#L1352 exists, and made a new lint struct checking method call expressions and its parents from scratch. I'll use that module instead.

For now I'm trying to implement lint for vector slice with [index..]

I'm still very new to this codebase, is this issue an urgent one? Because I need some time to study the code and learn what rustc_hir library can do, but it's totally fine if I have to pick other issues 👍

[giraffate]

Hi, is this issue already resolved? If so, it would be better to close this.

[JohnTitor]

Closing in favor of #5597.