Support && in if let expressions

[mdinger]

Update:

@kballard has a better suggestion than I did at #929 (comment) . Similar type of idea but borrows from Swift.

Original idea below.

---

Seems like a good idea to support && in if let expressions. I'm not sure about ||. It seems good from a consistency standpoint but I'm not sure if the the fact that the destructuring could result in different types could present a problem or not. In #525 it was a problem so I'd anticipate a problem here as well.

fn main() {
    // `op_op` (option option)
    let op_op = Some(Some(6));

    // Leads to deep nesting which is bad.
    if let Some(op) = op_op {
        if let Some(i) = op {
            println!("Matched {:?}, {:?}!", op, i);
        }
    }

    // It'd be nice to support the `&&` operator. `op_op` destructures
    // then `op` destructures. These would be directly equivalent.
    if let Some(op) = op_op &&
           Some(i) = op {
        println!("Matched {:?}, {:?}!", op, i);
    }

    // With `else`
    if let Some(op) = op_op {
        if let Some(i) = op {
            println!("Matched {:?}, {:?}!", op, i);
        } else {
            println!("Didn't");
        }
    } else {
        println!("Didn't");
    }

    // Would be replaced with
    if let Some(op) = op_op && 
           Some(i) = op {
            println!("Matched {:?}, {:?}!", op, i);
    } else {
        println!("Didn't");
    }

    let (op1, op2) = (Some(7), Some(8));

    // If `&&` is allowed, `||` shoud be also. Take first branch that
    // destructures. Otherwise do nothing.
    if let Some(i) = op1 ||
           Some(i) = op2 {
        println!("Matched {:?}!", i);
    }

    // Is equivalent to:
    if let Some(i) = op1 {
        println!("Matched {:?}!", i);
    else if let Some(i) = op2 {
        println!("Matched {:?}!", i);
    }

    // This is invalid because either `i` or `j` might appear in the
    // expression. The destructuring must use the same identifiers.
    if let Some(i) = op1 ||
           Some(j) = op2 {
        println!("Matched {:?}!", i);
    }

    // Adding an `else` clause:
    if let Some(i) = op1 {
        println!("Matched {:?}!", i);
    else if let Some(i) = op2 {
        println!("Matched {:?}!", i);
    } else {
        println!("Didn't");
    }

    // Would be equivalent to:
    if let Some(i) = op1 ||
           Some(i) = op2 {
        println!("Matched {:?}!", i);
    } else {
        println!("Didn't");
    }

    // These can go really deep:
    let op_by_4 = Some(Some(Some(Some(6))));

    // Would be either:
    if let Some(op_by_3) = op_by_4 {
        if let Some(op_by_2) = op_by_3 {
            if let Some(op) = op_by_2 {
                if let Some(i) = op {
                    println!("Matched {:?}, {:?}, {:?}, {:?}, {:?}!",
                              op_by_4, op_by_3, op_by_2, op, i);
                }
            }
        }
    }

    if let Some(op_by_3) = op_by_4 &&
           Some(op_by_2) = op_by_3 &&
           Some(op) = op_by_2 &&
           Some(i) = op {
        println!("Matched {:?}, {:?}, {:?}, {:?}, {:?}!",
                 op_by_4, op_by_3, op_by_2, op, i);
    }
}

Technically, && is typically used with bool so & or some other identifier (and?) could be valid here as well. I thought && made sense though because this is being interpreted in a slightly similar fashion to a boolean expression.

EDIT: Added else to examples and an example of a deeper nesting example.

[Marwes]

I don't see how '&&' adds anything since you can nest patterns, i.e.

    if let Some(Some(i)) = op_op {
        println!("Matched {:?}, {:?}!", op, i);
    }

'||' is basically there as well but its through '|' though it doesn't work for 'if let' yet.

[mdinger]

@Marwes Sorry. Maybe I simplified too much. The idea was to make this reddit problem a little nicer. In his case, he has more different enum variants but every else statement is essentially the same (I'm not sure they could collapse to a single else condition but I think they might. I looked at it more a few days ago).

Let me know if this example is better. I can modify the header problem then.

enum Enum {
    Null,
    Cons(Box<Enum>),
}

fn main() {
    let deep = Enum::Cons(Box::new(
               Enum::Cons(Box::new(
               Enum::Cons(Box::new(
               Enum::Null))))));

    // There are two issues. First is that nesting requires a dereference
    // every time. The second is that when structured like this, every `if let`
    // requires a separate `else` condition even if they are all identical.
    if let Enum::Cons(far_outer) = deep {
        if let Enum::Cons(outer) = *far_outer {
            if let Enum::Cons(inner) = *outer {
                if let Enum::Null = *inner {
                    println!("Null!");
                } else { println!("Failed!") }
            } else { println!("Failed!") }
        } else { println!("Failed!") }
    } else { println!("Failed!") }

    // This would avoid them.
    if let Enum::Cons(far_outer) = deep &&
           Enum::Cons(outer) = *far_outer &&
           Enum::Cons(inner) = *outer &&
           Enum::Null = *inner {
                    println!("Null!");
    } else { println!("Failed!") }    
}

[mdinger]

Also, | is being discussed in #935 but it's being used differently:

fn main() {
    let three = Some(3);
    let four = Some(4);

    // `|` is being used on alternations of a *single* destructure.
    // Destructure `three` and see if it matches either available
    // alternatives
    if let Some(3) | Some(4) = three { println!("Found 3 or 4"!) }

    // `||` is being used on *different* destructures of different variables.
    // Try to destructure `three` and if it fails, then try destructuring a
    // different variable `four` to determine if it matches a second condition.
    if let Some(3) = three ||
           Some(4) = four { println!("Found 3 or 4!") }

}

[mdinger]

I discovered it's possible to implement deref which may mitigate the issue though I'm not sure it could be used in the reddit case. This idea may be useful still. I'm not sure deref could fix all cases.

use std::ops::Deref;

#[derive(Debug)]
enum Enum {
    Num(End),
    Cons(Box<Enum>),
}

#[derive(Debug)]
struct End(i32);

impl Deref for Enum {
    type Target = End;

    fn deref(&self) -> &End {
        match *self {
            Enum::Cons(ref b) => b.deref(),
            Enum::Num(ref i) => i,
        }
    }
}

fn main() {
    let deep = Enum::Cons(Box::new(
               Enum::Cons(Box::new(
               Enum::Num(End(3))))));

    match *deep {
        End(i) => println!("Got `i`: {}", i),
    }
}

[lilyball]

if let came from Swift, and Swift 1.2 adds a syntax:

if let a = foo(), let b = a.bar(), let c = b.baz() where c > 2, let d = c.quux() {
    // all operations succeeded
} else {
    // something failed
}

(which actually can be shortened slightly, the 2nd and 3rd lets are unnecessary, it's only necessary on the first one and after a where clause, but I put it in there for clarity)

I'm inclined to say we should do something similar. I think this syntax makes more sense than trying to conceptually overload || and &&, especially since there's a conflict there where || and && are real operators and therefore would be parsed as part of the expression, but the comma is currently meaningless at that position.

[mdinger]

That's better than my idea.

[ftxqxd]

A more general feature that would allow this would be making PATTERN if let PATTERN = EXPR a pattern itself, sort of like a guard but for if let. That could even be used outside if let:

match foo() {
    Some(i) if let Some(num) = i.parse::<i32>() => ...,
    Some(i) if let Some(num) = i.parse::<f64>() => ...,
    ...
}

Used inside if let:

if let (((a if let b = a.bar()) if let c = b.baz()) if let d = c.quux()) = foo() {
    // all operations succeeded
} else {
    // something failed
}

Although that is a lot less readable than @kballard’s syntax, it’s more general. I’d probably prefer having both features: if let guards for flexible patterns everywhere, and the comma syntax as syntactic sugar for something like the above.

[lilyball]

@P1start it's more general, but as you say, it's less readable. I'm also concerned that it would not interact well with the restriction that you cannot bind by-move into a pattern guard. Note that this restriction is in place even if no other patterns attempt to bind the value in question. That restriction means you cannot replicate Swift 1.2's if let a = foo(), b = a with this proposed if the value is a by-move.

That said, I'm inclined to say that maybe we should allow if let in a pattern guard anyway, because it can be convenient in some cases, such as in your example (since numbers are not by-move). But we should also think about supporting Swift 1.2's syntax. We just won't be able to turn the enhanced if let syntax into pattern guards like you're suggesting.

[NeoLegends]

I want this. I've got quite some cases where I need intermediate processing between the destructuring (which is why the nested patterns don't apply so much) or need multiple results from destructuring at once. In those cases, the nests go really deep.

[djrenren]

Just ran into this issue myself. It would be immensely useful. In fact, as evidence of the usefulness (and feasibility) of this feature. Check out Manishearth/rust-clippy which utilizes a macro called if_let_chain! quite extensively:
https://github.com/Manishearth/rust-clippy/blob/ad1cd990549fdfc8ae9dcd4ea7eea851017eb042/clippy_lints/src/utils/higher.rs#L122

[SoniEx2]

Another option would be making let PATTERN = EXPRESSION an expression itself, returning a bool, true if the pattern matched, false otherwise. It'd bind values only during the current expression/statement so e.g.

let x = let Some(_) = option;

would make x true if option was Some, false otherwise, and e.g.

let x = let Some(b) = option && !b;

would make x true if option was Some(false), or false otherwise. You get the idea.

For ||, you'd have to bind the same name on both sides, just like with | in match, and they'd have to be the same types. As an example:

if let Some(x) = option || let x = default { x }

is equivalent to option.unwrap_or(default).

Etc. This requires much less special casing so it can just work everywhere. And the compiler can warn about let Some(x) = option; outside expressions.

[czakian]

I would also like this feature.