Code change:
have happily compiled. If we forget in the `match`, it will not. Rust helps us make sure to cover all of our bases. <ins> `match` expressions also allow us to get the values contained in an `enum` (also known as destructuring) as follows: ```{rust} enum OptionalInt { Value(int), Missing, } fn main() { let x = Value(5); let y = Missing; match x { Value(n) => println!("x is {}", n), Missing  => println!("x is missing!"), } match y { Value(n) => println!("y is {}", n), Missing  => println!("y is missing!"), } } ``` That is how you can get and use the values contained in `enum`s. It can also allow us to treat errors or unexpected computations, for example, a function that is not guaranteed to be able to compute a result (an `int` here), could return an `OptionalInt`, and we would handle that value with a `match`. As you can see, `enum` and `match` used together are quite useful! </ins> `match` is also an expression, which means we can use it on the right hand side of a `let` binding or directly where an expression is used. We could also implement the previous line like this:

Related discussion:
text: See: The keyword hasn't been introduced until that point but it's used in the code example which is confusing. I believe an if/else solution would be more explanatory, especially because the reader probably wants to see how to unpack the variant of . The same enum could then be used with the keyword in the beginning of the next chapter ().
You are correct. Nice catch!
Are you ok with simply reordering them ? Because introducing sum type without precedent knowledge of pattern matching is a bit pointles (or at least misses the fact that they are juste AWESOME for pattern matching). If you're ok with this I'll PR in a few hours :)
Maybe, if it flows okay, yeah. I do want to put SOME kind of mention of it first.
It's probably easy to find out what is doing by simply looking at it. This part of the tutorial is just a bit confusing and should be fixed. However, my main concern here is that the reader is left clueless on how to solve this problem with if/else: In fact, I really don't know how the equivalent code without would look like. I've briefly tried to figure it out and gave up.
With an Option you coul unwrap I guess. By the way why did you write a fake option enum ? Because that's basically what is done with this, it might be better to give out the real name
Because we haven't talked about generics yet.
Nicely done. However, my other concern, how this example could be done without , remains unresolved. I'm certain that I'm not the only one who wants to know how it works with before continue reading about . Should I open another issue for that matter?
I'm honestly not sure that it is possible with an arbitrary enum... You can test for some arbitrary values but i guess but that's it. Bt it's more an issue of sum types in general rather than a Rust issue (I can't find ways to do that in haskell nor in scala)
Alright, I expected something like this as I was unable to figure out how to write it without . I don't have much experience with statically typed languages, therefore the concept was new to me. If you are right, could we mention in the tutorial that it is actually not possible to write an equivalent solution with ? Certainly, I can't be the only one who was a bit puzzled.