24
TIL: All let statements use patterns [RUST] (lemmy.ml)
submitted 2 years ago by maegul@lemmy.ml to c/learningrustandlemmy@lemmy.ml
2 comments fedilink hide all child comments

A minor but interesting and illuminating point came up in a conversation that I thought was worth sharing, for those learning rust, in a separate post. I'm mostly just copy-and-pasting here.

TL;DR: The patterns you use in match statements and related syntax are (basically) available to you in let statements. This is how destructuring works!! And what they're for with let. But the patterns have to be "irrefutable"

IE, they have to always be able to match the expression/value.

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. All let statements involve patterns (as Ephera states). 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 that 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 those of the pattern.
    • EG, let (x, y, _) = (1, 2, 3); or Ephera's example below 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: 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

The nice and useful example provided by @Ephera@lemmy.ml (in the original comment):

struct Something(DifferentThing);

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

let Something(different_thing) = something;
  • Here, the variable something is a struct of type Something which contains one field of type DifferentThing.
  • In the final line, we're extracting that DifferentThing field with a pattern in a let statement.
  • IE, Something(different_thing) is the pattern. And it is irrefutable against all variables of type Something, as they have only one field.
top 2 comments
sorted by: hot top new old
[-] Sibbo@sopuli.xyz 8 points 2 years ago* (last edited 2 years ago)

This is outdated information. Nowadays, you can use let <pattern> = <expression> else <block>. This is called a let-else statement.

The pattern does not need to be irrefutable, as if it does not match, the else block is executed. But the block must diverge, i.e. contain a return, continue or break statement to avoid any code in which bindings made in the let statement would be valid.

[-] maegul@lemmy.ml 6 points 2 years ago

Thanks!!

Some quick searching uncovered the following:

Personally, skimming through that RFC left me pretty unconvinced. I think I'm going to ignore this and just assign/bind with match statements instead.

The RFC provides this example for why the let-else is "better":

Using match:

let features = match geojson {
    GeoJson::FeatureCollection(features) => features,
    _ => {
        return Err(format_err_status!(
            422,
            "GeoJSON was not a Feature Collection",
        ));
    }
};

Using let-else:

let GeoJson::FeatureCollection(features) = geojson else {
    return Err(format_err_status!(
        422,
        "GeoJSON was not a Feature Collection",
    ));
};

... and yea, for me, nah. Readability counts and match statements provide a lovely and consistent structure that lets you know what its doing.

The Drawbacks section in the RFC resonates with this. You gotta know to provide the else block if your pattern is refutable and you gotta be prepared to distinguish let-else statements and if-else expressions. EG, what's let PATTERN = if { a } else { b } else { c };??

Still cool though I guess.

this post was submitted on 18 Apr 2024
24 points (96.2% liked)

Learning Rust and Lemmy

460 readers
7 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.

Running Projects

Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities

Thumbnail and banner generated by ChatGPT.

founded 2 years ago
MODERATORS
maegul@lemmy.ml
sorrybookbroke@sh.itjust.works
Jayjader@jlai.lu