4 ms·

Noob to rust, is there a reason to use if / if let over match statements or is it just a style preference?

khuey 4y ago
Using "if let" is generally preferred style when there's only a single case that needs to be handled. (And I suspect that now that "if let ... else" is available that that will become the preferred style for handling two cases.)
- fasterthanlime 4y ago
  Yeah, clippy will yell at you if you use a match with a single arm - I personally don't hate matches with a single arm, but I'd rather not fight clippy (ie. come up with my own clippy config, enforce it onto every project I maintain etc.)
  - ratmice 4y ago
    I've hit this warning a few times where I expect to add additional match arms to be added in the future, always bugs me that clippy in that case steers you towards some change you know you'll end up undoing.
    - khuey 4y ago
      This is what #[allow(clippy::whatever)] is for.
    - pitaj 4y ago
      That's why they're warnings, not errors. I don't really understand the inability of some people to ignore warnings while they're working.
- pitaj 4y ago
  > And I suspect that now that "if let ... else" is available that that will become the preferred style for handling two cases. if let Pattern(binding) = thing { ... } else { ... } has been available for a long time. What was recently stabilized is let Pattern(binding) = thing else { ... }; which is syntax sugar for let binding = if let Pattern(binding) { binding } else { ... }; And facilitates easier unwrapping in early exit or default scenarios, without an extra level of indentation.
  - khuey 4y ago
    Yes, you're right of course. That's what I get for commenting while not fully awake :)
steveklabnik 4y ago
In the sense that "match is a superset of if and if let's functionality", yeah it's just a style preference. However, while style truly is subjective, I'm not sure anyone could convince me that match foo { true => println!("hello"), _ => {} } is the same or better than if foo { println!("hello"); } The RFC for "if let" has some good motivating examples as well https://rust-lang.github.io/rfcs/0160-if-let.html https://rust-lang.github.io/rfcs/0160-if-let.html
- tipsytoad 4y ago
  What about this code from the article ``` if cx.path == "/tags" { return tags::serve_list(cx).await; } else if cx.path.starts_with("/tags/") { return tags::serve_single(cx).await; } if cx.path == "/settings" { return settings::serve(cx).await; } if cx.path == "/search" { return search::serve(cx).await; } if cx.path == "/login" { return login::serve_login(cx).await; } if cx.path == "/patreon/oauth" { return login::serve_patreon_oauth(cx).await; } if cx.path == "/logout" { return login::serve_logout(cx).await; } if cx.path == "/debug-credentials" { return login::serve_debug_credentials(cx).await; } if cx.path == "/comments" { return comments::serve(cx).await; } if cx.path == "/latest-video" { return latest_video::serve(cx).await; } if cx.path == "/patron-list" { return patron_list::serve(cx).await; } if cx.path == "/index.xml" { return cx .serve_template("index.xml", Default::default(), mime::atom()) .await; } ```
  - steveklabnik 4y ago
    (Hacker News doesn't support markdown; indent any line two spaces to make it render as code) I would probably write that with a match, personally. I didn't say match was useless, just that if and if let pull their weight as features, in my opinion, even though you could express them as a match if you really wanted to.
  - fasterthanlime 4y ago
    Oh I wrote that code in anger forever ago, it had the merit of still working when I did the last round of cleanups on my website. I could've sworn at some point some paths had something slightly more involved (strip slashes, some starts_with or trim_prefix, etc.) but the snippet as you've copied it is certainly... not great.

Using "if let" is generally preferred style when there's only a single case that needs to be handled. (And I suspect that now that "if let ... else" is available that that will become the preferred style for handling two cases.)

fasterthanlime 4y ago
Yeah, clippy will yell at you if you use a match with a single arm - I personally don't hate matches with a single arm, but I'd rather not fight clippy (ie. come up with my own clippy config, enforce it onto every project I maintain etc.)
- ratmice 4y ago
  I've hit this warning a few times where I expect to add additional match arms to be added in the future, always bugs me that clippy in that case steers you towards some change you know you'll end up undoing.
  - khuey 4y ago
    This is what #[allow(clippy::whatever)] is for.
  - pitaj 4y ago
    That's why they're warnings, not errors. I don't really understand the inability of some people to ignore warnings while they're working.
pitaj 4y ago
> And I suspect that now that "if let ... else" is available that that will become the preferred style for handling two cases. if let Pattern(binding) = thing { ... } else { ... } has been available for a long time. What was recently stabilized is let Pattern(binding) = thing else { ... }; which is syntax sugar for let binding = if let Pattern(binding) { binding } else { ... }; And facilitates easier unwrapping in early exit or default scenarios, without an extra level of indentation.
- khuey 4y ago
  Yes, you're right of course. That's what I get for commenting while not fully awake :)

steveklabnik 4y ago

In the sense that "match is a superset of if and if let's functionality", yeah it's just a style preference. However, while style truly is subjective, I'm not sure anyone could convince me that match foo { true => println!("hello"), _ => {} } is the same or better than if foo { println!("hello"); } The RFC for "if let" has some good motivating examples as well https://rust-lang.github.io/rfcs/0160-if-let.html https://rust-lang.github.io/rfcs/0160-if-let.html

tipsytoad 4y ago
What about this code from the article ``` if cx.path == "/tags" { return tags::serve_list(cx).await; } else if cx.path.starts_with("/tags/") { return tags::serve_single(cx).await; } if cx.path == "/settings" { return settings::serve(cx).await; } if cx.path == "/search" { return search::serve(cx).await; } if cx.path == "/login" { return login::serve_login(cx).await; } if cx.path == "/patreon/oauth" { return login::serve_patreon_oauth(cx).await; } if cx.path == "/logout" { return login::serve_logout(cx).await; } if cx.path == "/debug-credentials" { return login::serve_debug_credentials(cx).await; } if cx.path == "/comments" { return comments::serve(cx).await; } if cx.path == "/latest-video" { return latest_video::serve(cx).await; } if cx.path == "/patron-list" { return patron_list::serve(cx).await; } if cx.path == "/index.xml" { return cx .serve_template("index.xml", Default::default(), mime::atom()) .await; } ```
- steveklabnik 4y ago
  (Hacker News doesn't support markdown; indent any line two spaces to make it render as code) I would probably write that with a match, personally. I didn't say match was useless, just that if and if let pull their weight as features, in my opinion, even though you could express them as a match if you really wanted to.
- fasterthanlime 4y ago
  Oh I wrote that code in anger forever ago, it had the merit of still working when I did the last round of cleanups on my website. I could've sworn at some point some paths had something slightly more involved (strip slashes, some starts_with or trim_prefix, etc.) but the snippet as you've copied it is certainly... not great.