explicit_counter_loop suggests `.zip()` when `.take()` would be clearer

[devjgm]

Summary

The explicit_counter_loop clippy lint does a good job of detecting when an explicit loop counter is in use and suggesting alternatives. However, in some cases I see it suggesting a somewhat complex usage of .zip(), when a simpler usage of .take() would likely be clearer.

Reproducer

Code:

pub fn foo() {
    let mut base = 100;
    const MAX: usize = 10;
    for _ in 0..MAX {
        std::hint::black_box(base);
        base += 1;
    }
}

Current output:

❯ cargo +nightly-2026-02-26 clippy
warning: the variable `base` is used as a loop counter
 --> src/lib.rs:4:5
  |
4 |     for _ in 0..MAX {
  |     ^^^^^^^^^^^^^^^ help: consider using: `for (base, _) in (100..).zip((0..MAX))`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_counter_loop
  = note: `#[warn(clippy::explicit_counter_loop)]` on by default

warning: `bad-clippy-suggestion` (lib) generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s

Desired output:

I think the suggested fix should be:

for base in (100..).take(MAX)

As compared to the current suggestion of

for (base, _) in (100..).zip((0..MAX))

Version

❯ rustc  +nightly-2026-02-26 -vV
rustc 1.95.0-nightly (1ed488274 2026-02-25)
binary: rustc
commit-hash: 1ed488274bec5bf5cfe6bf7a1cc089abcc4ebd68
commit-date: 2026-02-25
host: aarch64-apple-darwin
release: 1.95.0-nightly
LLVM version: 22.1.0

Additional Labels

No response

[zayutaha]

@rustbot claim