this post was submitted on 17 Apr 2024
9 points (84.6% liked)

Learning Rust and Lemmy

393 readers
1 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 1 year ago
MODERATORS
maegul@lemmy.ml
sorrybookbroke@sh.itjust.works
Jayjader@jlai.lu
9
How common is if let syntax and is it "worth" it? (rust-book.cs.brown.edu)
submitted 11 months ago by maegul@lemmy.ml to c/learningrustandlemmy@lemmy.ml
6 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] Ephera@lemmy.ml 4 points 11 months ago (1 children)

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@lemmy.ml 3 points 11 months ago* (last edited 11 months ago) (1 children)

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
[–] Ephera@lemmy.ml 2 points 11 months ago

Excellent research! 🙂