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.)

> 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.

Yes, you're right of course. That's what I get for commenting while not fully awake :)

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.)

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.

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.

This is what #[allow(clippy::whatever)] is for.

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

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;
    }

```

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.

(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.