Concise Control Flow with if let - The Rust Programming Language
rust-book.cs.brown.edu

I can’t help but suspect it doesn’t offer much and you may as well just use match statements for whenever you want pattern matching, however many times it might be slightly more verbose than what you could do with if let.

I feel like I’d easily miss that pattern matching was happening with if let but will always know with match what’s happening and have an impression of what’s happening just from the structure of the code.

  • Lmaydev@programming.devEnglish
    8·
    7 months ago
    // Make optional of type Option<i32>
let optional = Some(7);

match optional {
    Some(i) => {
        println!("This is a really long string and `{:?}`", i);
        // ^ Needed 2 indentations just so we could destructure
        // `i` from the option.
    },
    _ => {},
    // ^ Required because `match` is exhaustive. Doesn't it seem
    // like wasted space?
};

    I think the rust book gives a good example. The match syntax is just a waste here.

    So if you have a single expression that you want to match I think it is worth it.

    As with most syntax, the more you read it the more you’ll just spot it without thinking.

  • Ogeon@programming.devEnglish
    51·
    7 months ago

    I would say it’s very useful when you are looking for one specific pattern, which happens a lot with Option<T>. Plus, being able to chain it in if / else if / else chains helps with organizing the code. It generally doesn’t grow as deep as with match.

    That said, match is fantastic and it’s totally fine to prefer using it. if let and let else are there for those cases when you tend to discard or not need to use the other values than the matched one. How often that happens depends on what you are doing.

  • Ephera@lemmy.mlEnglish
    4·
    7 months ago

    I’m not a massive fan of it – some Rust newbies on our team do get confused by it – but it can improve readability in places and it does fit into the greater scheme of Rust in that you can also write things like this:

    struct Something(DifferentThing);

let something = Something(DifferentThing::new());

let Something(different_thing) = something;

    So, any time you see a let, it’s actually secretly pattern matching. The variable name you provide is just a wildcard pattern.

    • maegul (he/they)@lemmy.mlOPMEnglish
      3·
      7 months ago

      EDIT: I copied this into a separate post: https://lemmy.ml/post/14593192

      yea, great point … I hadn’t considered the consistency with destructuring (which seems silly in hindsight).

      For those who aren’t aware, here’s the first section in The Book on patterns in let statements.

      I think, if this is confusing, there are two points of clarification:

      1. As Ephera states, all let statements involve patterns. They’re all let PATTERN = EXPRESSION. For ordinary variable binding, we’re just providing a basic pattern that is essentially like a wildcard in that it will match the totality of any expression and so be bound to the full/final value of the expression.
        • It’s only when the pattern becomes more complex that the pattern matching part becomes evident, as elements of the value/expression are destructured into the pattern.
        • EG, let (x, y, _) = (1, 2, 3); or Ephera’s example above let Something(different_thing) = something; which extracts the single field of the struct something into the variable different_thing` (handy!).
      2. let statements must use irrefutable patterns. That is, patterns that cannot fail to match the expression. For example, against a tuple, (x, y, _) will always match. Another way of putting it, is that irrefutable patterns are about destructuring not testing or conditional logic.
        • if let statements on the other hand can take both irrefutable patterns and refutable, but are really intended to be used with refutable patterns as they’re intended for conditional logic where the pattern must be able to fail to match the expression/value.
        • See The Book chapter on refutability