The Rust Programming Language

Booleans, Conditionals, Statements, and Expressions

Richard Feldman

Richard Feldman

Vendr, Inc.
The Rust Programming Language

Check out a free preview of the full The Rust Programming Language course

The "Booleans, Conditionals, Statements, and Expressions" Lesson is part of the full, The Rust Programming Language course featured in this preview video. Here's what you'd learn in this lesson:

Richard demonstrates booleans in Rust, the syntax of conditionals, discusses that and expression in Rust is something that evaluates to a value, that a statement does not evaluate to a value, and provides multiple examples for each. The Rust compiler allows the convenience of not using the return keyword only on functions and else if statements ending on an expression.


Transcript from the "Booleans, Conditionals, Statements, and Expressions" Lesson

>> And finally, let's talk about Booleans. So Booleans, there's two of them, you got your true, and you got your false, those are the only two Booleans. And so here we defined, should we go fast to be true, and should we go slow to be false. If you want you can use as to convert between a Boolean and u8, because behind the scenes Boolean is just a u8 that's kinda the smallest thing that hardware will let you do.

Theoretically, you can represent a Boolean as just a bit, but there isn't any hardware that I'm aware of, that actually has precision that's small, usually the smallest storage size they have is a byte. You could do something fancier if you wanna actually only take up a bit. So true will evaluate to 1, and false will value to 0, because that's basically how it stores them.

True is 1 and false is 0 at runtime. There's also double equals in Rust, which is a way to compare things. Of note, double equals is what's known as structural equality, which is to say that if I were to put two collections here and compare that with double equals, Rust would actually go through normally and actually compare all the contents of both of those collections.

It wouldn't be reference equality you might be used to in some languages. Also worth noting that this double equals is really the only equals you've got in Rust, there is no triple equals. So always use double equals, because that's the only one there is and it's probably gonna do what you want.

Okay, let's talk about conditionals briefly because these use Booleans. So here we have an if conditional, so I say if cats greater than 1, println multiple cats. We can also throw an else on there, and say need more cats. That's totally valid. Of note, compared to a lot of languages with similar syntax in Rust, you do not need parentheses around this, you can leave them off.

But, you do always need the curly braces. So I know in a lot of languages you can say, if parentheses and then leave off the curly braces, Rust is not having that, in Rust, you always have to have the curly braces, which I think is a good decision personally.

Also of note, this condition right here, this cats greater than 1, this thing has to be a Boolean. There's no truthiness in Rust, this can't be a number, it can't be a string, it can't be anything. If this is not exactly a Boolean value, you'll get an error from the compiler.

Fortunately, using double equals you can always pretty easily get something into a Boolean if that's what you want. You can also do else if, so, else if in Rust is basically exactly the same as it is a lot of languages. And, what to take a brief detour here and talk about statements and expressions.

So an expression in Rust, is something that evaluates to a value. So for example, here's an expression, cats is greater than 1000. That's an expression, because that will evaluate to either true, or false. That's the value. This also breaks down into sub expressions, like cats itself is an expression, and 1000 itself is an expression.

Each of those they evaluate to a value, so they are expressions. So both of them individually are expressions, and also the entire thing with them put together is an expression. Similarly, with a function call, we can say okay, this is an expression, this is an expression, this whole function call is an expression, and the entire thing there is an expression.

All of these are expressions, they're things that evaluate to a value. A statement on the other hand, does not evaluate to a value. So, the canonical example of this we've been using are our calls to println, this does not evaluate to any particularly useful value, so there's a semicolon at the end, which kinda is a good clue that.

So, a statement, generally speaking will end with a semicolon. It's not always true, like conditionals, like if can be used the statement and you don't have to put a semicolon at the end. But, anytime you do see a semicolon, you're definitely dealing with a statement. Okay, why does this distinction matter?

Well, it matters because in a number of cases, the Rust compiler sorta gives you these little conveniences, when you choose an expression over a statement. So here's an example, we had this function earlier, multiply both x and y, both taking f64, returning an f64. Then we said return x times y.

And in a language like JavaScript for example, you need that return keyword. But in Rust, as long as you wanna return this expression here, you can say okay, I don't wanna have my return statement here, I wanna just let the compiler infer that. And the way that this works is basically, the last expression in a function, in this case, x times y being our expression, is automatically returned.

So you don't need to write out return, you don't need to use the return keyword, instead, you can just say, x times y, and that's it. Both of these functions are exactly the same. There's no performance trade off here, this is just something that the Rust compiler does for you.

So this is the rule, if a function ends with an expression rather than a statement, it automatically returns that expression. But of note, you don't wanna put a semicolon here. If you put a semicolon, then this becomes a statement, and then Rust says, Hey, I thought you were gonna return something, how come you didn't return an f64 like I thought you were gonna?

So basically, either say return and semi colon, or leave off both the return and the semi colon, and either of those are gonna be equivalent. Now I mentioned this in the context of ifs, because this is also a thing that you can do with ifs. It's not just functions.

So actually, each of these if branches, follows the same rule as functions do, which is to say, if you want to, you can leave off the semicolon here and have the entire branch, evaluate to whatever the expression is here. So here's an example of that. I can say let message equals, and then use if basically like a ternary, if you're familiar with those, where I'm saying, okay, if cats is greater than 1, then message will be equal to this expression right here, multiple cats.

Cats greater thousand, then message will get set to this expression right here, and otherwise message will get set to need more cats. So here, although each of these branches does not have a semicolon, this is an example where I do need a semicolon at the end there, which is sorta going with the let, because lets are statements.

I'm gonna highlight this semicolon little bit, because yeah, I definitely forget this all the time whenever I'm doing this like, let equals if. And the compiler error messages uncharacteristically unhelpful. So, if you're gonna use let equals and if, definitely don't forget that semicolon.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now