`if some_var.is_some_and(|x| some_expr)` is the current way to do that. It is less flexible and doesn't actually bind `x` into the conditional body (hence the proposal) but works today.

Thanks for the suggestion. It does avoid a nested if-statement, so agreed it's useful.

Yeah, but I almost always want to pattern match out the value when I do that.

As I said in the post you can also write this:

    if let (Some(x), true) = (my_option, expr) {

But then it doesn't short-circuit. (expr is evaluated in all cases, even when the optional is None).

Both approaches are also weird. It'd be much better to just fix the language to make the obvious thing work.

I personally use two conditionals for such case. Yes, I might have written Rust too long to say this but it is more like a minor ergonomic fix and any solution should be generalizable into other use cases. The eventually accepted syntax, `if let PAT = EXPR {&& EXPR}` [1], is okay by itself but not (yet) generalized and that's my current complaint about it. The whole `{let PAT = EXPR &&} EXPR` should have been a valid expression in my opinion. (This exact suggestion is not in the RFC, the closest would be making `let PAT = EXPR` a boolean expression which really looks like a mistake.) Maybe I should check whether this was ever suggested...

[1] https://rust-lang.github.io/rfcs/2497-if-let-chains.html

> I personally use two conditionals for such case.

Me too. But that often makes my logic worse. Its quite common to want to share the same code in the else branch, for example:

    if let Some(val) = opt {
        if expr {
            // ....
        } else {
            do_complex_stuff();
        }
    } else {
        do_complex_stuff();
    }

I don't want to copy+paste that complex code in two places. And you can fix that in turn with a named block & named break statements or a function - but .... whyyyyy? Why is this even a thing? The solution is so obvious. The RFC you linked to fix it is fine, and 6 years old now. My sister has a child in grade school who was born after that RFC was drafted.

Yes, you can work around this hole in the language any number of ways with ugly code. But I don't want to do that. I want to use a good language.

I'm worried that you want a "good" language at any circumstance, which is not even generally possible but also at odds with other aspects of languages. This still counts as minor for me because it is just slightly annoying and doesn't make something impossible or much harder to read (and the readability varies enough that this threshold is much higher than this case).

> I'm worried that you want a "good" language at any circumstance, which is not even generally possible but also at odds with other aspects of languages.

Yes, I do want a good programming language. I agree its relatively minor compared to the other issues I talked about in the blog post.

In what way is this at odds with other aspects of the language? If its at odds with the rest of the language, why is this feature being added?

https://rust-lang.github.io/rfcs/2497-if-let-chains.html

Mainly a long-term consequence in teaching and readability. The RFC was accepted only after considering such trade-offs.

> Coming from Go, I was surprised that something like > > if let Some(x) = > some_var; expr(x) { } > > isn't a thing.

The same thing in C++17:

    if (auto x = something();
        expr1(x)) {}
    else if (expr2(x)) {}

It's really neat to have the variable scoped to the if/else-clause.