Change:
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. Cheers.
Thanks a lot for the remark, it's exactly the kind of comment needed, if you see others don't hesitate to open new issues :) I'll try to add this tonight or tomorrow.

Discussion:
Value(int), Missing, } <del> 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!"), } } </del> ``` This enum represents an `int` that we may or may not have. In the `Missing`

to `int`s, though. We can make it usable by any type, but we haven't quite gotten there yet! <del> You can have any number of values in an enum: </del> <ins> You can also have any number of values in an enum: </ins> ```{rust} enum OptionalColor {

} ``` <del> Enums with values are quite useful, but as I mentioned, they're even more useful when they're generic across types. But before we get to generics, let's talk about how to fix these big `if`/`else` statements we've been writing. We'll do that with `match`. </del> <ins> And you can also have something like this: ```{rust} enum StringResult { StringOK(String), ErrorReason(String), } ``` Where a `StringResult` is either an `StringOK`, with the result of a computation, or an `ErrorReason` with a `String` explaining what caused the computation to fail. This kind of `enum`s are actually very useful and are even part of the standard library. As you can see `enum`s with values are quite a powerful tool for data representation, and can be even more useful when they're generic across types. But before we get to generics, let's talk about how to use them with pattern matching, a tool that will let us deconstruct this sum type (the type theory term for enums) in a very elegant way and avoid all these messy `if`/`else`s. </ins> # Match

matching,' which `match` is an implementation of. So what's the big advantage here? Well, there are a few. First of all, `match` <del> does 'exhaustiveness checking.' Do you see that last arm, the one with the </del> <ins> enforces 'exhaustiveness checking.' Do you see that last arm, the one with the </ins> underscore (`_`)? If we remove that arm, Rust will give us an error: ```{ignore,notrust}

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: