Clarify let_underscore documentation

[blyxyas]

Fixes #10867
changelog: [let_underscore]: Clarify its documentation

[rustbot]

r? @llogiq

(rustbot has picked a reviewer for you, use r? to override)

[llogiq]

The assign-to-underscore pattern doesn't so much ignore the type as the binding. That said, I'm unsure how to best formulate this.

[blyxyas]

I used this phrasing because the original PR did it.
#10356

[...] Alternatively, they can drop the let keyword to truly just ignore the value no matter what.

[Fuuzetsu]

I made the original ticket. I'm still unsure about why we'd warn that let _ = foo() is not fine because type can change at any time but _ = foo() is allowed... Why is former preferred to latter, even if we intentionally want to ignore the type? Neither stops or flags a type change of foo().

The only difference that I know of is that you can say let _x = foo() for a while to remove a binding from play for a little bit, the type changes (unknowingly) and you try to bring it back with let x = foo() and get a nasty surprise. _x = foo() is not allowed so it's much more obvious that you're ignoring the result completely rather than temporarily hiding a binding. However I don't think that's what the clippy lint is about, right? If it is, it should probably be much more explicit.

[Centri3]

let _ = foo() is not fine because type can change at any time but _ = foo() is allowed... Why is former preferred to latter

It's not preferred. let _ = and _ = function the same afaik, _ = is likely allowed as you're explicitly opting out of specifying the type (as you physically cannot give a type annotation); as blyxyas said, it's essentially the same as just allowing the lint altogether, but is a ton more ergonomic

[blyxyas]

AFAIK, both let _ = ... and _ = ... drop the value when used (meaning that the type is irrelevant, as it's immediately dropped). So, I think the original lint gave the option to use _ = ... instead of a let as a way to "allow" the lint.

I'm not sure it should have been implemented in the lint in the first place, but now that's here, I also don't see a reason to remove it. It's less verbose than an #[allow] and the lint is restriction, so it isn't very important.

[Fuuzetsu]

If we could add a line like "to allow this anyway, use _ = ..." then it'd be clearer. It's just that it currently sounds like a solution to the lroblem rather than a way to disable the hint and ignore it.

[blyxyas]

@Fuuzetsu what do you think about the new commit? This has been in the middle of my notifications for 3 weeks now, I think it's ready 😅

[Fuuzetsu]

@Fuuzetsu what do you think about the new commit? This has been in the middle of my notifications for 3 weeks now, I think it's ready 😅

Looks better to me. I suppose there are other ways of saying the same thing such as or drop the `let` keyword to ignore this lint. but we could be here forever. Let's take what we have. Thank you.

[blyxyas]

@llogiq What do you think about the current phrasing?

[hikari-no-yume]

I think it is very unintuitive that let _ = would be be forbidden, but _ = wouldn't. What if there were separate lints for these two, and by default the former enables the latter, or something like this? You could then choose to allow the former but deny the latter if you want to use this pattern, but otherwise you'd get the intuitive behaviour where a type must be specified.

[blyxyas]

I'll just close this, 107 days for 4 words of documentation is kinda ridiculous.