New lint against let $pat: _ = $expr;

[dtolnay]

What it does

Generalizing from #10441 -- a new lint for this would supersede that issue, which was originally reported as a false negative against the existing let_underscore_untyped lint.

In this GitHub search (not sure how stable the URL is -- it's a search for /let [a-zA-Z0-9_]+: _ =( |$)/ language:rust) I noticed a surprisingly large amount of code doing:

let pattern: _ = expression;

There are 610 search results. From skimming about a dozen of them, I couldn't identify any reason that the code would need to be written in this way. It is universally equivalent to:

let pattern = expression;

and it would be helpful for Clippy to guide newbies in this preferred direction.

Lint Name

let_with_type_underscore

Category

complexity

Advantage

Reduced line noise. : _ provides zero clarity or utility.

Drawbacks

No response

Example

fn main() {
    let v: _ = 1;
    println!("{v}");
}

Could be written as:

fn main() {
    let v = 1;
    println!("{v}");
}

[blyxyas]

@rustbot claim

[matthiaskrgr]

Interesting..
I grepped in my local cargo cache (~4200 crates) and this showed up only 16 times (2 unique occurrences, two in ra_ap_parser and one in winit

[mmirate]

I couldn't identify any reason

Here's one.

Unboxed futures are undoubtedly good for performance compared to boxed futures; but they can have gigantic names when they are generated with combinators rather than async/await notation. You'd think that that isn't a problem because you don't have to look at the name, just await it immediately, use the compiler and/or rust-analyzer to identify the Output type and work from there. Unfortunately, sometimes a Future's definition is lengthy enough and its use-site complicated enough, that it becomes best for the Future itself to be named-out into a let.

rust-analyzer has a helpful feature where it will place an inlay on any unhinted let, indicating the type that it inferred (i.e. the type that you could have written if needed). Theoretically there is no need for rust-analyzer to place the exact full name of the type, since this is only displayed in the editor and not given to the compiler. Nonetheless, rust-analyzer currently will happily emit multiple levels of Future combinator nesting and trait casting rather than emitting an impl Trait-in-let pseudo-Rust notation. When it does so, the result is a giant pile of line-noise in the editor. An underscore hint to silence rust-analyzer's inlay, is the best that can be done to the status quo.

Without an underscore hint:

Versus with it:

I was very surprised to discover that there are people who actually write let pattern: _ = expression; for no reason.