Now it's time to talk about enums. enums in rust are more like algebraic data types in Haskell than C like enums. You specify an enum with a keyword enough the name of the enum in capital camel case, and the names of the variants in a block. You can stop there if you want, and just use it like that, in which case, it is sort of like an enum and see just namespace into the enum and away you go. However, the real power of arrest enough comes from associating data and methods with the variants, you can always have a named variant with no data. A variant can have a single type of data, a tuple of data, or an anonymous struct of data.

And enough is sort of like a union in C only so much better. If you create an enum the value can be any one of these variants. For example, your dispenser item could be an empty with no data associated with it, but you can tell that it's an empty Or it could be an ammo with a single byte in it. Or it could be a things with a string and assigned 32 bit integer in it, or it could be a place with x and y is 30 twos. It can be any one of those but only one at a time. Even better, you can implement functions and methods for an email.

You can also use enums with generics option is a generic enough in the standard library that you will use all the time the T and angle brackets means any type, you don't have to use t you could use some other valid identifier but the idiomatic thing to do in rust is to use T or some other capital letter. The option enough represents when something is either absent or present. If you're trying to reach for a no or nil value, like in other languages, you probably want to use an option in rust. You either have some value wrapped into some variant or you have none. I'm going to use an option for the rest of the examples in this Section. Because enums can represent all sorts of data, you need to use patterns to examine them.

If you want to check for a single variant, you use the if let expression, if let takes a pattern that will match one of the variants. If the pattern does match, then the condition is true and the variables inside the pattern are created for the scope of the if left block. If the pattern doesn't match, then the condition is false. This is pretty handy if you care about one variant matching or not, but not as great if you need to handle all the variants at once. In that case, you use the match expression which is match a variable whose type supports matching like an EM the body of the match and braces where you specify patterns followed by double arrows which are equal signs followed by greater than symbols pointing to an expression that represents the return value of that arm of the match. Match expressions require you to write a branch arm for every possible outcome.

In other words, the patterns in a match expression must be exhaustive. A single underscore all by itself is a pattern that matches anything and can be used for a default or anything else branch. Note that even though you will often see blocks as the expression for a branch arm any expression will do, including things like function calls and bear values. Either all branch arms need to return nothing or all branch arms need to return the same type. Remember that if you actually use the return value of an expression that ends in a curly brace like match if left or if or a nested block, then you have to put a semicolon after the closing brace. If you don't use the return value of a braced expression, then rust lets you cheat and leave off the semicolon.

I want to talk a bit more in depth about two special enums. What's so special about them is that they're used all over the standard library so you will encounter them constantly first. Let's look a little more at option. Here's the definition of option. Again, as I said earlier option is used whenever something might be absent. Here's how you could create a nun variant of an option.

I specified the type that some will wrap an angle brackets after the option. Notice that I don't have a use statement bringing into scope option or its variants, some or none from the standard library. Since option and its variants are used so much. They're already included in the standard Prelude which is the list of items from the standard library that are always brought into scope by default. If you ever use option with a concrete type, then the compiler will infer the type which means you can leave the type annotation off of the declaration most of the time there's a handy helper method called is sum that returns true if x is the sum variant. There's also an is none method that does just the opposite option implements the into iterator trait.

So you can also treat it similar To a vector of zero or one items and put it in a for loop, you ought to read through the methods for option because you'll end up using them a lot. There are a whole bunch more of them that I won't go over. The other important em is result result is used whenever something might have a useful result or might have an error. This turns up especially often in the i o module. Here's the definition of the result enum First, you'll see that the type wrapped by okay and the type rep by air are both generic but independent of each other. Second, the must use annotation makes it a compiler warning to silently drop a result you have to do something with it rust strongly encourages you to look at all possible errors and make a conscious choice what to do with each one.

Anytime you deal with IO failure is a possibility. So results are used a lot there. Like I said earlier. Let's see it in action. Here I bring standard file system file and disk scope and then Try to open a file. This returns a result because the file might not get opened successfully.

Since I dropped the result without doing anything with it, I get this compiler warning, unused standard result result that must be used. The point is ignoring errors is not a safe thing to do. So let's go to something to do with our result, the simplest thing you could choose to do is to unwrap the result with the unwrap method. If the result isn't Okay, then this gives you the file structure that you wanted. If the result is an error, then this crashes the program. In some cases crashing the program may be what you want.

In any case, you get to choose another option is the expect method. It's exactly the same as unwrap except that the string that you pass to expect is also printed in the crash output. So you can provide yourself a little bit of custom context as to why the crash occurred. Just like option there helper methods like is okay and is error that return Boolean Here we know that unwrap will never crash because we've made sure it wasn't okay already. Of course, you can always do fall pattern matching as well. Here I match on a result and execute different blocks depending on what I got back.

In the next video, we'll talk about closures.