Summary
I am in the habit of never writing let _ = something. I prefer to write let _: Type = something. (See let_underscore_untyped for rationale.)
But let_underscore_future trips on this pattern, even when the type is specified. The alternative formulation (suggested by clippy) involving mem::drop is a lot noisier and hard to read.
I think let_underscore_future should be content if the programmer has explicitly written a future type. Eg, in my program I have this:
// This future was Ready and has returned the value,
// which is in `got`. We don't want the completed future.
let _: Pin<Box<dyn Future<Output = _>>> = reqs.swap_remove(goti);
Or to put it another way, all these let_underscore_xxx lints should be strict subsets of let_underscore_untyped
Lint Name
let_underscore_future
Reproducer
I tried this code:
use std::pin::Pin;
#[tokio::main]
async fn main() {
let _: Pin<Box<dyn Future<Output = ()>>> = Box::pin(async {});
}
I saw this happen:
warning: non-binding `let` on a future
--> src/main.rs:5:5
|
5 | let _: Pin<Box<dyn Future<Output = ()>>> = Box::pin(async {});
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: consider awaiting the future or dropping explicitly with `std::mem::drop`
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.95.0/index.html#let_underscore_future
= note: `#[warn(clippy::let_underscore_future)]` on by default
I expected to see this happen:
It lints without errors. (Note that this is a rather contrived example.)
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=d2d1ba5e575f7fd85f303cdf6a845fb2
Version
rustc 1.94.0-beta.2 (23a44d3c7 2026-01-25)
binary: rustc
commit-hash: 23a44d3c70448c08dc6a2fc13c1afceab49f2bb9
commit-date: 2026-01-25
host: x86_64-unknown-linux-gnu
release: 1.94.0-beta.2
LLVM version: 21.1.8
Additional Labels
No response
Summary
I am in the habit of never writing
let _ = something. I prefer to writelet _: Type = something. (Seelet_underscore_untypedfor rationale.)But
let_underscore_futuretrips on this pattern, even when the type is specified. The alternative formulation (suggested by clippy) involvingmem::dropis a lot noisier and hard to read.I think
let_underscore_futureshould be content if the programmer has explicitly written a future type. Eg, in my program I have this:Or to put it another way, all these
let_underscore_xxxlints should be strict subsets oflet_underscore_untypedLint Name
let_underscore_future
Reproducer
I tried this code:
I saw this happen:
I expected to see this happen:
It lints without errors. (Note that this is a rather contrived example.)
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=d2d1ba5e575f7fd85f303cdf6a845fb2
Version
Additional Labels
No response