Skip to content

let_underscore_future should not trigger if type of discarded value specified #16991

@ijackson

Description

@ijackson

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't have

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions