Spurious irrefutable_let_patterns warning with let-chain

[RalfJung]

Code

#![feature(let_chains)]

fn max() -> usize {
    42
}

fn main() {
    if let mx = max() && mx < usize::MAX {
        // ...
    }
}

Current output

warning: leading irrefutable pattern in let chain
 --> src/main.rs:7:8
  |
7 |     if let mx = max() && mx < usize::MAX {
  |        ^^^^^^^^^^^^^^
  |
  = note: this pattern will always match
  = help: consider moving it outside of the construct
  = note: `#[warn(irrefutable_let_patterns)]` on by default

Desired output

(no warning)

Rationale and extra context

This code naturally expresses "please call that function and then do something if the return value satisfies a condition". Putting the let binding outside the if would be bad as then it remains in scope after the if, which is not the intent. I could wrap it in an extra layer of curly braces but that increases the overall indentation level.

I think this warning should never trigger for let chains.

Other cases

Rust Version

current nightly

Anything else?

No response

[kurikomoe]

another example:

#[allow(irrefutable_let_patterns)]
if let errCode = GetLastError() && errCode != ERROR_NO_MORE_ITEMS {
    let _ = dbg!(errCode);
    // logging the errCode to db, etc
}

Honestly, I don't want to introduce the errCode into the outer scope; I just want to keep it inside this if-else branch to avoid the possibility of using the variable elsewhere.

[RalfJung]

Seems like the lint was introduced in #49469 as part of #44495 -- previously, this was a hard error. With #57535, the lint was made warn-by-default.

@rust-lang/lang I'd like to propose to further weaken this lint from warn-by-default to allow-by-default or even entirely remove it.

[traviscross]

Do you want to weaken or remove this lint in general, or do you just want it to not fire on let chains?

[joshtriplett]

I think there's a reasonable case for not applying it to let chains, specifically. In the absence of let chains, if let name = expr() { ... } is unnecessary and always true, and it seems reasonable to lint on that. But with let chains, it makes sense to bind something for use later in the chain.

I seem to recall at some point that we talked about making it not fire for any subsequent let in the chain, but keeping it for the first one since that one can be moved out. (But, of course, that's not true for while let.)

[RalfJung]

I think there's a reasonable case for not applying it to let chains, specifically.

That works for me.

[RalfJung]

I seem to recall at some point that we talked about making it not fire for any subsequent let in the chain, but keeping it for the first one since that one can be moved out.

Both of the examples posted above argue against that: moving it out extends the scope of the binding, which might not be desired.

[traviscross]

If someone wants to put up a PR to make it not fire on let chains and nominate that, I'll propose FCP merge on it. I'd estimate that being likely to save us a step here.

[joshtriplett]

@RalfJung I'm aware, but that isn't necessarily a reason to allow it, just an argument that someone might want to write it that way.

The downside of allowing it for let chains in general is that it may not be intentional, and sometimes this catches errors where you meant to write a refutable pattern.

But nonetheless, I'd be 👍 for allowing it for let chains, for now, with the possibility of coming up with something more specific in the future to catch potential mistakes.

[RalfJung]

I'm aware, but that isn't necessarily a reason to allow it, just an argument that someone might want to write it that way.

Fair. It just seemed odd to make a suggestion that would change nothing for 100% of the examples considered in this issue.

[traviscross]

@rustbot labels -I-lang-nominated +I-lang-radar

We talked about this in the @rust-lang/lang call today. We decided we just wanted to rip out the irrefutable_let_patterns lint entirely. Given the existing dead code and unused variable lints, we just weren't seeing a lot of incremental value in this one, and we could think of many reasons for people to write code that would hit this. Whoever does this should ensure that dead_code catches e.g. let () = () else { /* dead code */ }; and if let () = () { .. } else { /* dead code */ } and whatnot, and then nominate the PR for us.

And CC @rust-lang/clippy in the event that clippy might want to add something here.

[jnkr-ifx]

I find the irrefutable_let_patterns lint beneficial occasionally because I have a bad habit of writing if let x = ... when I'm trying to unwrap an Option. (I picked up the habit from Swift, where if let x = ... is syntactic sugar for if let Some(x) = ...).

#![allow(irrefutable_let_patterns)]

fn foo() -> Option<u32> {
    None
}

fn main() {
    if let x = foo() {
        println!("{:?}", x);
    }
}

This prints None, with no warning.

In most cases this mistake will lead to a type error really quickly because the Option isn't unwrapped in the body of the if statement -- I had to use {:?} instead of {} to write that example -- but I can definitely remember seeing this lint fire and remind me "hey, you're not writing Swift" before, especially when I was newer to Rust.

[traviscross]

We did talk about how some aspects of the lint might be most beneficial to new users, and that's why we pinged the clippy team here, as adding a lint to help such users might better fit in their domain.

[tmandry]

The comparison to Swift is interesting; I'd forgotten about that syntax.

The specific case of if let x = ... being confused with if x == ... was mentioned, and it was brought up that this would usually result in an unused variable warning. Of course the snippet you posted doesn't hit this since x is used, and since debug-printing is agnostic to whether the type of the binding x is an option. One question is whether we think cases like this that aren't caught by unused variables or the type checker are ever "important".

That said, with example from @jnkr-ifx I've switched back to thinking most non-chain uses of if let qualify as either likely bugs or needless divergence.

What pushed me toward removing the lint is that I don't want overly paternalistic lints that limit expressiveness needlessly. It's true that we've already experienced that with some of the "irrefutable" lints (particularly in the where clause department where we've already relaxed it some). In fact I felt some annoyance about this arising in the discussion today.

But I also don't buy the case I've heard so far for how it's nice to support if let x = foo() { ... } outside of a let chain. The potential for confusion with Swift feels much more concrete to me. The place where I sort of buy wanting it is something like this:

if let Some(x) = foo() {
  ...
} else if let Ok(y) = bar() {
  ...
} else if let z = baz() {
  ...
}

And I don't know, maybe I would want to write that for aesthetic reasons, but it isn't so bad to write else { let z = baz(); ... }. Crucially it's also clearer to the reader, who naturally would expect any usage of if to be followed by some condition.

In contrast, I find the example with a let chain brought up by @kurikomoe extremely motivating. Assigning to a variable and checking a condition on its value immediately is a very common pattern, and it's also common to only need that variable to exist inside the if block. Other languages have forms like this for the same reason.

Outside of let chains, my thinking now is this is one of the places where Rust should err more in the direction of Go (simple and uniform) than Haskell (elegant and inscrutable). In terms of design goals, I would argue that "clarity of purpose" and "correctness by construction" are both on the side of keeping the lint but removing it for let chains.

[traviscross]

In that case, I feel like the lint you might want is about a trivially true condition rather than about an irrefutable pattern. These all seem about the same to me:

if let () = () { .. }
if let () = () && true { .. }
if let () = () && 0 == 0 { .. }
if true { .. }
if 0 == 0 { .. }

Similarly, a trailing else if let .. { .. } strikes me about the same as a trailing else if .. { .. } with any other trivially true conditional expression.

[traviscross]

We're already convinced on let chains, but for posterity, here's what the most motivating case for that looks like to me:

if let x = op_one()
&& check_one(x)
&& let y = op_two(x)
&& check_two(y)
&& let z = op_three(y)
&& check_three(z)
{
    ..
}

That is, we don't want to get y at all if the test on x fails, etc. This factoring is saving us from having to nest many conditionals, which is really the whole point of let chains.

[RalfJung]

These all seem about the same to me:

I don't agree for if true. That can be quite useful to write during debugging etc and it's annoying to have the compiler complain about it. Java does that and people resort to if 0 == 0 etc to work around it...

[traviscross]

Yes, that's actually why I feel the same about if let x = foo() { .. }. Because you start with if let x = foo() && x > 8 && x < 16 { .. }, and then for debugging (etc.) you want to truncate off parts of that conditional, so you'll delete characters until you maybe have if let x = foo() { .. }, and then the compiler will complain and want you to unwrap that body. You can't just say if true { .. } here without moving around that binding. And at that point, you could just truncate it all the way to { let x = foo(); .. } if you still want to keep the indent and the block semantics.

So I don't really see a principled or practical case for distinguishing an irrefutable let expression from any other trivially true expression. If we want to nag people to unwrap these blocks (or at least remove the if), it seems to apply to both, and if we don't, that seems to apply to both as well.

[joshtriplett]

Generally speaking, if I'm in the middle of debugging, and have deleted some code or added true && to a conditional or similar, I don't mind getting compiler warnings, because I'm going to ignore the ones I caused while I'm debugging. If anything, they're a useful reminder that debugging is in progress.

[flip1995]

And CC @rust-lang/clippy in the event that clippy might want to add something here.

Should this lint be removed from rustc, it could of course be "down-lifted" to Clippy. I can see it in the complexity (warn-by-default) group in Clippy.

[scottmcm]

Java does that and people resort to if 0 == 0 etc to work around it...

I don't know the specifics for Java, but for C# at least the reason that if true is different is that C# doesn't have loop, so there's a bunch of rules for when while exp is considered that the code afterwards is unreachable.

And at least in C#, while 0 == 0 and while true are the same. You have to do something more complicated -- usually using a static, like while string.Empty == "" -- in order to bypass that. The language spec spends many pages describing what the exact rules are here, because it affects type checking.

---

I like that these checks are type-based in Rust, and thus if let () = () is different from if true to me.

[traviscross]

We discussed this in the lang call today without consensus.

[RalfJung]

But to be clear, the consensus of not emitting the lint for chains still stands, right? So we could have a PR to adjust that while the question around non-chains remains open? (The issue was originally meant to be about chains only anyway.)

[traviscross]

We didn't discuss it particularly, but yes, my estimate would be that such a PR would be an easy FCP for us.

Last we discussed the point, people also seemed OK with not firing the lint on while let (even without a chain).

[traviscross]

Thinking about the Swift behavior further — that if let x = .. is if let Some(x) = .. — if we were to be persuaded on that basis, then I'm increasingly not sure that there'd be a consistent case for relaxing this lint so as to not fire on let chains. Because just as we might have type confusion with,

if let x = Some("hello") {
    if format!("{x:?}") == "hello" {
        do_important_work(); //~ Silently never reached.
    }
}

we could equally as well have type confusion with:

if let x = Some("hello")
&& format!("{x:?}") == "hello"
{
    do_important_work(); //~ Silently never reached.
}

[RalfJung]

I think the fact that another language picked that convention (a convention that is rather at odds with how we handle option types in Rust) should not stop us from supporting idioms that are very natural in Rust, and that are awkward to express without firing this lint, such as the two examples at the top of this post.

[tmandry]

So I don't really see a principled or practical case for distinguishing an irrefutable let expression from any other trivially true expression. If we want to nag people to unwrap these blocks (or at least remove the if), it seems to apply to both, and if we don't, that seems to apply to both as well.

The reason is that the meaning of if true {}and if 0 == 0 {} is universal and unambiguous, while the meaning of if let x = foo() {} is not.

[traviscross]

Because of Swift, I presume. The angle I was pushing there was that, regardless of how ambiguous or unambiguous we feel that let x = .. is, let x = .. and let x = .. && true should be equal in that respect. It seems strange that adding && true should disambiguate that case.¹

So if we write:

if let x = .. { .. } else { .. }
if let x = .. && true { .. } else { .. }

I feel like I'd expect the same warnings (or lack thereof) on both of those independent of our feelings about the ambiguousness of let x = ... And if we warn on that second case, then it'd feel strange to me to not also warn on

if true { .. } else { .. }

since the condition is "obviously" just as trivial as let x = .. && true (within Rust).

(@scottmcm made the point that the triviality of an arbitrary let expression is a type-space calculation rather than a value-space one, and I agree that's an interesting and distinguishing point, though the common case of let x = .. is always as trivially true and syntactically decidable as true is.)

The later point I'd press is similarly in the spirit that the chained case may not be so different from the unchained case, if we think that let x = .. is ambiguous, though that would be unfortunate, because the use cases here are compelling.

Footnotes

1. To argue the counterpoint preemptively, we could say that && true is like adding an if true pattern guard, and indeed match .. { _ if true => .., .. } does make the arm non-exhaustive currently. I don't feel like that's particularly fundamental, and that we'd be within our rights to make _ if true an exhaustive arm (and also, let chains are probably more like nested conditionals rather than pattern guards). But anyway, I think the separate later point is the stronger one. ↩

[RalfJung]

I think the lint should only warn for cases that are trivially true and where that is likely an accident. If someone writes if true, that's not an accident, that's an expression of intent, and we shouldn't warn (and we currently do not warn).

The trouble with if let x = ... is that it can be both an expression of intent, as in the examples above, and an accident, if someone comes from Swift. But I'd rather not prioritize programmers coming from just one particular other language over useful Rust-side idioms. Most Rust programmers do not come from Swift, after all.

The argument for warning only in chains is that it helps us disambiguate those two cases: without a chain, the chance that this is intentional is much lower, since there's much less of a use for such an idiom on the Rust side, and thus the chances that this is a Swift-induced mistake is bigger and a lint is more likely to find a true mistake.

[traviscross]

I don't know. The only time there could be type confusion is when the user isn't otherwise constraining the type sufficiently, and it's hard for me to tell what's going to be more or less likely there. You have to work at it a bit anyway for this to be a problem, and it's not clear to me that

if let x = foo_returns_option()
&& format!("{x:?}") == "hello"
{
    do_important_work(); //~ Silently never reached.
}

would be less likely to be a problem in that respect than anything else.

Perhaps it would be a challenging lint to write, but it seems the appropriate lint for Swift users would be targeted on this, where you said if let x = .. or if let x = .. && .. and then did not later constrain the type of x in such a way as to make it clear you know that you're in Rust and not Swift.

(We could call the lint, e.g., if_lets_ambiguous_with_swift.)

[RalfJung]

I didn't say the Swift confusion is impossible in the chained case. But an irrefutable pattern is less likely to be a Swift confusion when there is a chain, mostly because there's a higher chance that someone actually wrote this on purpose without being confused.