Is it bad style to match a bool?

1

I used clippy for the first time today and ran into a warning for using match on a bool, rather than an if/else.

The reason I do this is that I align my braces, so it's more concise to write:

match condition
{
    true => do_something(),
    false => do_something_else()
}

than...

if condition
{
    do_something();
}
else
{
    do_something_else();
}

Is there a good reason to prefer the second version to the first, and is the first really horrible and confusing?

Thanks!

2 Likes
2

Well, I would say that the second solution is better because you don't have to explitely say true or false, but Rust's obligation to put {} for if else statements gets anoying when you have only one line inside.

I did not find anything regarding this and would be OK with both solutions. Plus, if anyone isn't happy with your match, it's a simple fix.

3 Likes
3

It's considered bad style to align the braces, so the idiomatic way is


if condition {
    do_something();
} else {
    do_something_else();
}

But, of course, you can always do what you want!

6 Likes
4

I would rather phrase it as "unidiomatic": Rust community overwhelmingly uses K&R style for braces. There's nothing inherently good or bad in any particular style.

8 Likes
5

Well, except for the following one :smiling_imp:

if condition                                    {
    do_something()                             ;}
else                                            {
    do_something_else()                        ;}
21 Likes
6

Yes, I mirrored the language of the OP, but generally prefer "unidiomatic"
as well. Thanks <3

2 Likes
7

For years I've had the color scheme of my editor set to show punctuation at 40% opacity. I'll reset this now so when I come across this style you quoted I'll be sure to notice it so I can get rightfully mad.

5 Likes
8

Think the fact I felt I had to ask this question in the first place has convinced me to just use if/else.

Not sure I can bring myself to change brace style yet though D:

1 Like
9

Rustfmt should have a mode for that.

2 Likes
10

It hasn't been mentioned I don't think so I'll just say one major benefit to matching bools for a particular edge case:

Say you have combinations of bools: is_fruit = true, eaten = false, etc.

My example is trivial, but you can imagine a situation where you need to handle all possible outcomes, and the nice thing about match statements is they enforce that some behavior exists for all cases exhaustively:

match (is_fruit, eaten) {
  (true, true) => "we need more fruit!".to_string()
  (false, true) => "was that even fruit?".to_string()
// compiler error! Match not exhaustive!
}

So that's the only time I use match instead of if, but I'm interested to hear if there's a more idiomatic way to my suggestions.

And for those who say, just have nested ifs, well yes until the programmer forgets! match is much harder to "forget" - you'd have to forget to put an additional boolean inside the tuple, which, c'mon, that's only 1 line of code to remember...

4 Likes
11

Please don't bump old threads.

2 Likes
12

@jhpratt that wasn't intended and i'm sorry. How do I comment without bumping? Or is the answer just don't comment at all in which case why isn't this topic just locked from further input?

I'm used to SO where answers often times extend several years as things change and new features become available

13

Threads here close 3 months after the last reply now, but that wasn't always the case. Just don't comment or open a new thread with a summary if you have a question.

Discourse has a pretty linear/chronological format. Posts don't shuffle by vote and are rarely edited for things other than typo corrections and the like; instead one typically makes a new comment conversation-style. If someone bumps an old thread and I don't notice, I'll read a bunch of multi-year-old comments until I catch on, like if you had to read the entire history of an SO topic first or something.

14

Fair, but I wasn't asking a question - I genuinely believed I was providing a valuable answer to the OP's question. I am new to Rust and mentioned I'd like to hear what others say only to assert my neophyte status with the language so my answer didn't lead to "blind leading the blind".

What I'm hearing though is old threads that don't auto-close should probably be avoided, unless I have stunning information to share which I likely won't for another 5 - 10 years once I reach expert level anyway.

2 Likes