mirror of
https://github.com/rust-lang-cn/book-cn.git
synced 2025-01-26 09:18:42 +08:00
739 lines
19 KiB
Markdown
739 lines
19 KiB
Markdown
|
# Enums
|
|||
|
|
|||
|
Next, let’s look at a feature of Rust that’s similar to structs, but also
|
|||
|
different. Enumerations, or ‘enums’ as they’re more commonly referred to,
|
|||
|
are an extremely powerful feature of Rust. Enums are a feature that are in many
|
|||
|
languages, but what they can do is different per-language. Rust’s enums are
|
|||
|
most similar to enums in functional languages.
|
|||
|
|
|||
|
Here’s an example of an enum:
|
|||
|
|
|||
|
```rust
|
|||
|
enum IpAddrKind {
|
|||
|
V4,
|
|||
|
V6,
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
This enum represents the kind of an IP address. There are two major standards
|
|||
|
used for IP addresses: version four, and version six. Any IP address can be either
|
|||
|
a version four address, or a version six address. But it cannot be both kinds at
|
|||
|
the same time. This is where enums get their name: they allow us to enumerate all
|
|||
|
of the possible kinds that our value can have.
|
|||
|
|
|||
|
We can create values of `IpAddrKind` like this:
|
|||
|
|
|||
|
```rust
|
|||
|
# enum IpAddrKind {
|
|||
|
# V4,
|
|||
|
# V6,
|
|||
|
# }
|
|||
|
|
|||
|
let four = IpAddrKind::V4;
|
|||
|
let six = IpAddrKind::V6;
|
|||
|
```
|
|||
|
|
|||
|
Note that the variants of the enum are namespaced under its name, and we use
|
|||
|
the double colon to separate the two.
|
|||
|
|
|||
|
Enums have more tricks up their sleeves, however. Thinking more about our IP
|
|||
|
address type, we don’t have a way to store the actual data of the IP address,
|
|||
|
we only know what kind it is. Given that you just learned about structs, you
|
|||
|
might tackle this problem like this:
|
|||
|
|
|||
|
```rust
|
|||
|
enum IpAddrKind {
|
|||
|
V4,
|
|||
|
V6,
|
|||
|
}
|
|||
|
|
|||
|
struct IpAddr {
|
|||
|
kind: IpAddrKind,
|
|||
|
address: String,
|
|||
|
}
|
|||
|
|
|||
|
let home = IpAddr {
|
|||
|
kind: IpAddrKind::V4,
|
|||
|
address: String::from("127.0.0.1"),
|
|||
|
};
|
|||
|
|
|||
|
let loopback = IpAddr {
|
|||
|
kind: IpAddrKind::V6,
|
|||
|
address: String::from("::1"),
|
|||
|
};
|
|||
|
```
|
|||
|
|
|||
|
We’ve used a struct to bundle the two values together: now we keep the kind
|
|||
|
with the value itself. This design isn’t bad, exactly, but it wouldn’t be
|
|||
|
considered idiomatic Rust. We can represent the same thing with just an enum:
|
|||
|
|
|||
|
```rust
|
|||
|
enum IpAddr {
|
|||
|
V4(String),
|
|||
|
V6(String),
|
|||
|
}
|
|||
|
|
|||
|
let home = IpAddr::V4(String::from("127.0.0.1"));
|
|||
|
|
|||
|
let loopback = IpAddr::V6(String::from("::1"));
|
|||
|
```
|
|||
|
|
|||
|
We can attach data to each variant of the enum directly. No need for an extra
|
|||
|
struct. But beyond that, this approach is better than using a struct alongside
|
|||
|
our enum because we can attatch different kinds of data to each variant.
|
|||
|
Imagine that instead of a `String`, we would prefer to store a `V4` as its four
|
|||
|
individual components, while leaving the `V6` variant as a `String`. With our
|
|||
|
struct, we’d be stuck. But enums deal with this case with ease:
|
|||
|
|
|||
|
```rust
|
|||
|
enum IpAddr {
|
|||
|
V4(u32, u32, u32, u32),
|
|||
|
V6(String),
|
|||
|
}
|
|||
|
|
|||
|
let home = IpAddr::V4(127, 0, 0, 1);
|
|||
|
|
|||
|
let loopback = IpAddr::V6(String::from("::1"));
|
|||
|
```
|
|||
|
|
|||
|
You can put any kind of data inside of an enum variant, including another enum!
|
|||
|
The `IpAddr` enum is [in the standard library][IpAddr], but it embeds two different
|
|||
|
structs inside of its variants:
|
|||
|
|
|||
|
```rust
|
|||
|
struct Ipv4Addr {
|
|||
|
// details elided
|
|||
|
}
|
|||
|
|
|||
|
struct Ipv6Addr {
|
|||
|
// details elided
|
|||
|
}
|
|||
|
|
|||
|
enum IpAddr {
|
|||
|
V4(Ipv4Addr),
|
|||
|
V6(Ipv6Addr),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
[IpAddr]: http://doc.rust-lang.org/std/net/enum.IpAddr.html
|
|||
|
|
|||
|
Here’s an enum with a variety of types embedded in its variants:
|
|||
|
|
|||
|
```rust
|
|||
|
enum Message {
|
|||
|
Quit,
|
|||
|
Move { x: i32, y: i32 },
|
|||
|
Write(String),
|
|||
|
ChangeColor(i32, i32, i32),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
* `Quit` has no data associated with it at all.
|
|||
|
* `Move` includes an anonymous struct inside of it.
|
|||
|
* `Write` includes a single `String`.
|
|||
|
* `ChangeColor` includes three `i32`s.
|
|||
|
|
|||
|
We haven’t talked a lot about how to access the data inside an enum variant,
|
|||
|
however. To do that, let’s move on to some new Rust syntax that’s especially
|
|||
|
useful with enums: `match`.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# Option
|
|||
|
|
|||
|
Now that we have a handle on enums, let's combine them with a feature that we
|
|||
|
talked a little bit about in the previous chapter: generics.
|
|||
|
|
|||
|
Programming language design is often though of as which features you include,
|
|||
|
but it's also about which features you leave out. Rust does not have a feature
|
|||
|
that is in many other languages: 'null'. In languages with this feature,
|
|||
|
variables can have two states: null or not-null.
|
|||
|
|
|||
|
The inventor of this concept has this to say:
|
|||
|
|
|||
|
> I call it my billion-dollar mistake. At that time, I was designing the first
|
|||
|
> comprehensive type system for references in an object-oriented language. My
|
|||
|
> goal was to ensure that all use of references should be absolutely safe, with
|
|||
|
> checking performed automatically by the compiler. But I couldn't resist the
|
|||
|
> temptation to put in a null reference, simply because it was so easy to
|
|||
|
> implement. This has led to innumerable errors, vulnerabilities, and system
|
|||
|
> crashes, which have probably caused a billion dollars of pain and damage in
|
|||
|
> the last forty years.
|
|||
|
>
|
|||
|
> - Tony Hoare "Null References: The Billion Dollar Mistake"
|
|||
|
|
|||
|
The problem with null values is twofold: first, a value can be null or not, at
|
|||
|
any time. The second is that if you try to use a value that's null, you'll get
|
|||
|
an error of some kind, depending on the language. Because this property is
|
|||
|
pervasive, it's extremely easy to make this kind of error.
|
|||
|
|
|||
|
Even with these problems, the concept that null is trying to express is still a
|
|||
|
useful one: this is a value which is currently invalid or not present for some
|
|||
|
reason. The problem isn't with the concept itself, but with the particular
|
|||
|
implementation. As such, Rust does not have the concept of null, but we do have
|
|||
|
a type which can encode the concept of a value being present. We call this type
|
|||
|
`Option<T>`, and it looks like this:
|
|||
|
|
|||
|
```rust
|
|||
|
enum Option<T> {
|
|||
|
Some(T),
|
|||
|
None,
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
This type is [provided by the standard library][option], and is so useful that
|
|||
|
it's even in the prelude; you don't need to import it explicitly. Furthermore,
|
|||
|
so are its variants: you can say `Some` and `None` directly, without prefixing
|
|||
|
them with `Option::`.
|
|||
|
|
|||
|
[option]: ../std/option/enum.Option.html
|
|||
|
|
|||
|
Here's an example of using `Option<T>`:
|
|||
|
|
|||
|
```rust
|
|||
|
let some_number = Some(5);
|
|||
|
let some_string = Some("a string");
|
|||
|
|
|||
|
// If we only say None, we need to tell Rust what type of Option<T> we have.
|
|||
|
let absent_number: Option<i32> = None;
|
|||
|
```
|
|||
|
|
|||
|
Let's dig in. First, you'll notice that we used the `<T>` syntax when defining
|
|||
|
`Option<T>`: it's a generic enum. `Option<T>` has two variants: `Some`, which
|
|||
|
contains a `T`, and `None`, which has no data associated with it. In some
|
|||
|
sense, `None` means 'null', and `Some` means 'not null'. So why is this any
|
|||
|
better than null?
|
|||
|
|
|||
|
In short, because `Option<T>` and `T` are different types. That's a bit too
|
|||
|
short though. Here's an example:
|
|||
|
|
|||
|
```rust,ignore
|
|||
|
let x = 5;
|
|||
|
let y = Some(5);
|
|||
|
|
|||
|
let sum = x + y;
|
|||
|
```
|
|||
|
|
|||
|
This will not compile. We get an error message like this:
|
|||
|
|
|||
|
```text
|
|||
|
error: the trait `core::ops::Add<core::option::Option<_>>` is not implemented
|
|||
|
for the type `_` [E0277]
|
|||
|
|
|||
|
let sum = x + y;
|
|||
|
^~~~~
|
|||
|
```
|
|||
|
|
|||
|
Intense! What this error message is trying to say is that Rust does not
|
|||
|
understand how to add an `Option<T>` and a `T`. They're different types! This
|
|||
|
shows one of the big advantages of an `Option<T>` type: if you have a type that
|
|||
|
may or may not exist, you have to deal with that fact before you can assume it
|
|||
|
exists. In other words, you have to convert an `Option<T>` to a `T` before you
|
|||
|
can do `T` stuff with it. This helps catch one of the most common issues with
|
|||
|
null, generally: assuming that something isn't null, when it actually is.
|
|||
|
|
|||
|
So, how _do_ you get a `T` from an `Option<T>`? The option type has a large
|
|||
|
number of methods that you can check out in [its documentation], and becoming
|
|||
|
familiar with them will be extremely useful in your journey with Rust.
|
|||
|
|
|||
|
[its documentation]: ../std/option/enum.Option.html
|
|||
|
|
|||
|
But we want a deeper understanding than that. If we didn't have those methods
|
|||
|
defined for us already, what would we do? For that, we need a new feature: `match`.
|
|||
|
# Match
|
|||
|
|
|||
|
Rust has an extremely powerful control-flow operator: `match`. It allows us to
|
|||
|
compare a value against a series of patterns, and then execute code based on
|
|||
|
how they compare. Remember the `Option<T>` type from the previous section?
|
|||
|
Let's say that we want to write a function that takes an `Option<i32>`, and
|
|||
|
if there's a value inside, add one to it.
|
|||
|
|
|||
|
This function is very easy to write, thanks to `match`. It looks like this:
|
|||
|
|
|||
|
```rust
|
|||
|
fn plus_one(x: Option<i32>) -> Option<i32> {
|
|||
|
match x {
|
|||
|
None => None,
|
|||
|
Some(i) => Some(i + 1),
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
let five = Some(5);
|
|||
|
let six = plus_one(five);
|
|||
|
let none = plus_one(None);
|
|||
|
```
|
|||
|
|
|||
|
Let's break down the `match`! At a high-level, the `match` expression looks
|
|||
|
like this:
|
|||
|
|
|||
|
```text
|
|||
|
match condition {
|
|||
|
pattern => code,
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
First, we have the `match` keyword. Next, we have a condition. This feels very
|
|||
|
similar to an `if` expression, but there's a big difference: with `if`, the
|
|||
|
condition needs to be a boolean. Here, it can be any type.
|
|||
|
|
|||
|
Next, we have a "match arm". That's the part that looks like `pattern =>
|
|||
|
code,`. We can have as many arms as we need to: our `match` above has two
|
|||
|
arms. An arm has two parts: a pattern, and some code. When the `match`
|
|||
|
expression executes, it compares the condition against the pattern of each arm,
|
|||
|
in turn. If the pattern matches the condition, the associated code is executed,
|
|||
|
and the rest of the patterns are not checked. If it doesn't match, execution
|
|||
|
continues to the next arm.
|
|||
|
|
|||
|
Let's examine the first execution of `plus_one()` in more detail. In the above
|
|||
|
example, `x` will be `Some(5)`. Let's compare that against each arm:
|
|||
|
|
|||
|
```text
|
|||
|
None => None,
|
|||
|
```
|
|||
|
|
|||
|
Does `Some(5)` match `None`? No, it's the wrong variant. So let's continue.
|
|||
|
|
|||
|
```text
|
|||
|
Some(i) => Some(i + 1),
|
|||
|
```
|
|||
|
|
|||
|
Does `Some(5)` match `Some(i)`? Why yes it does! We have the same variant. But
|
|||
|
what about `i`? In a pattern like this, we can declare new bindings, similarly
|
|||
|
to what we did with `let`. So in this case, the code part of the match arm will
|
|||
|
have a binding, `i`, which corresponds to the `5`.
|
|||
|
|
|||
|
With this arm, the code portion is `Some(i + 1)`. So we do exactly that: we
|
|||
|
take `i`, which is `5`, add one to it, and create a new `Some` value with our
|
|||
|
sum inside.
|
|||
|
|
|||
|
Because `match` is an expression, the value of the overall expression becomes
|
|||
|
the value of the arm that executed. So the value of this `match` expression
|
|||
|
will be `Some(6)`. And since our `match` is the only expression in the
|
|||
|
function, the value of the `match` will be the value of the function, and so
|
|||
|
`Some(6)` is our return value as well, which is exactly what we were shooting
|
|||
|
for.
|
|||
|
|
|||
|
Now let's consider the second call. In this case, `x` is `None`. We enter the
|
|||
|
`match`, and compare to the first arm:
|
|||
|
|
|||
|
```text
|
|||
|
None => None,
|
|||
|
```
|
|||
|
|
|||
|
Does `None` match `None`? Yup! And so we return `None`. There's no value to add
|
|||
|
to.
|
|||
|
|
|||
|
Combining `match` and enums together is extremely powerful. You'll see this
|
|||
|
pattern a lot in Rust code: `match` against an enum, binding to the data
|
|||
|
inside, and then executing code based on it. It's a bit tricky at first, but
|
|||
|
once you get used to it, you'll wish you had it in languages that don't support
|
|||
|
it. It's consistently a user favorite.
|
|||
|
|
|||
|
## Matches are exhaustive
|
|||
|
|
|||
|
There's one other aspect of `match` we didn't talk about. Consider this version
|
|||
|
of `plus_one()`:
|
|||
|
|
|||
|
```rust,ignore
|
|||
|
fn plus_one(x: Option<i32>) -> Option<i32> {
|
|||
|
match x {
|
|||
|
Some(i) => Some(i + 1),
|
|||
|
}
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
A bug! We didn't handle the `None` case. Luckily, it's a bug Rust knows how to catch.
|
|||
|
If we try to compile this code, we'll get an error:
|
|||
|
|
|||
|
```text
|
|||
|
error: non-exhaustive patterns: `None` not covered [E0004]
|
|||
|
match x {
|
|||
|
Some(i) => Some(i + 1),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
Rust knows that we did not cover every possible option, and even knows which
|
|||
|
pattern we forgot! This is referred to as being "exhaustive", we must exhaust
|
|||
|
every last option possible in order to be valid!
|
|||
|
|
|||
|
This analysis isn't perfect, however. This will also error:
|
|||
|
|
|||
|
```rust,ignore
|
|||
|
# let some_u8_value = 0u8;
|
|||
|
match some_u8_value {
|
|||
|
0 => println!("zero"),
|
|||
|
1 => println!("one"),
|
|||
|
2 => println!("two"),
|
|||
|
3 => println!("three"),
|
|||
|
4 => println!("four"),
|
|||
|
5 => println!("five"),
|
|||
|
6 => println!("six"),
|
|||
|
7 => println!("seven"),
|
|||
|
// We won't write out all of the arms here, but imagine that there are more
|
|||
|
// arms corresponding to the rest of the numbers.
|
|||
|
254 => println!("two-hundred and fifty-four"),
|
|||
|
255 => println!("two-hundred and fifty-five"),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
Even though a `u8` can only have valid values of zero through 255, Rust isn't
|
|||
|
quite smart enough to understand we've covered all the cases. In order to fix
|
|||
|
this, we can use a special pattern, `_`:
|
|||
|
|
|||
|
```rust
|
|||
|
# let some_u8_value = 0u8;
|
|||
|
match some_u8_value {
|
|||
|
0 => println!("zero"),
|
|||
|
1 => println!("one"),
|
|||
|
2 => println!("two"),
|
|||
|
3 => println!("three"),
|
|||
|
4 => println!("four"),
|
|||
|
5 => println!("five"),
|
|||
|
6 => println!("six"),
|
|||
|
7 => println!("seven"),
|
|||
|
// ...
|
|||
|
254 => println!("two-hundred and fifty-four"),
|
|||
|
255 => println!("two-hundred and fifty-five"),
|
|||
|
_ => panic!("can't ever happen"),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
The `_` pattern matches anything at all, and so with it as the final pattern,
|
|||
|
Rust can understand that we have all our bases covered. It's not only used for
|
|||
|
this sort of exhastiveness issue, though. It's useful any time we don't want to
|
|||
|
deal with a number of cases. Consider this scenario: if we wanted to print out
|
|||
|
something one one, three, five, and seven:
|
|||
|
|
|||
|
```rust
|
|||
|
# let some_u8_value = 0u8;
|
|||
|
match some_u8_value {
|
|||
|
1 => println!("one"),
|
|||
|
3 => println!("three"),
|
|||
|
5 => println!("five"),
|
|||
|
7 => println!("seven"),
|
|||
|
_ => (),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
The `_` pattern will match all the other cases, and `()` will do nothing, it's
|
|||
|
the unit value.
|
|||
|
|
|||
|
## More about patterns
|
|||
|
|
|||
|
As we've just seen, patterns are powerful, yet complex. Let's take a whole
|
|||
|
section to cover all of the things that they can do.
|
|||
|
# if let
|
|||
|
|
|||
|
There's one more advanced control flow structure we haven't discussed: `if
|
|||
|
let`. Imagine we're in a situation like this:
|
|||
|
|
|||
|
```rust
|
|||
|
# let some_option = Some(5);
|
|||
|
match some_option {
|
|||
|
Some(x) => {
|
|||
|
// do something with x
|
|||
|
},
|
|||
|
None => {},
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
We care about the `Some` case, but don't want to do anything with the `None`
|
|||
|
case. With an `Option`, this isn't _too_ bad, but with a more complex enum,
|
|||
|
adding `_ => {}` after processing just one variant doesn't feel great. We have
|
|||
|
this boilerplate arm, and we have an extra level of indentation: the code that
|
|||
|
does something with `x` is indented twice, rather than just once. We really want
|
|||
|
a construct that says "Do something with this one case, I don't care about the
|
|||
|
others."
|
|||
|
|
|||
|
Enter `if let`:
|
|||
|
|
|||
|
```rust
|
|||
|
# let some_option = Some(5);
|
|||
|
if let Some(x) = some_option {
|
|||
|
// do something with x
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
`if let` takes a pattern and an expression, separated by an `=`. It works
|
|||
|
exactly like a `match`, where the expression is given to the `match` and the
|
|||
|
pattern is its first arm. In other words, you can think of `if let` as syntax
|
|||
|
sugar:
|
|||
|
|
|||
|
```rust,ignore
|
|||
|
if let pattern = expression {
|
|||
|
body
|
|||
|
}
|
|||
|
|
|||
|
match expression {
|
|||
|
pattern => body,
|
|||
|
_ => {}
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
And in fact, we can include an `else` and it becomes the body of the `_`
|
|||
|
case:
|
|||
|
|
|||
|
```rust,ignore
|
|||
|
if let pattern = expression {
|
|||
|
body
|
|||
|
} else {
|
|||
|
else_body
|
|||
|
}
|
|||
|
|
|||
|
match expression {
|
|||
|
pattern => body,
|
|||
|
_ => else_body,
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
In other words, it's the high-level construct we were originally looking for:
|
|||
|
do something with a single pattern.
|
|||
|
# Patterns
|
|||
|
|
|||
|
We've mentioned 'patterns' a few times so far: they're used in `let` bindings,
|
|||
|
in function arguments, and in the `match` expression. Patterns have a lot of
|
|||
|
abilities, so in this section, we'll cover all of the different things they can
|
|||
|
do. Any of these abilities work in any place where a pattern is used.
|
|||
|
|
|||
|
## Literals & _
|
|||
|
|
|||
|
You can match against literals directly, and `_` acts as an any case:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = 1;
|
|||
|
|
|||
|
match x {
|
|||
|
1 => println!("one"),
|
|||
|
2 => println!("two"),
|
|||
|
3 => println!("three"),
|
|||
|
_ => println!("anything"),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
This prints `one`.
|
|||
|
|
|||
|
# Multiple patterns
|
|||
|
|
|||
|
You can match multiple patterns with `|`:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = 1;
|
|||
|
|
|||
|
match x {
|
|||
|
1 | 2 => println!("one or two"),
|
|||
|
3 => println!("three"),
|
|||
|
_ => println!("anything"),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
This prints `one or two`.
|
|||
|
|
|||
|
## ref and ref mut
|
|||
|
|
|||
|
Usually, when you match against a pattern, bindings are bound by value.
|
|||
|
This means you'll end up moving the value out:
|
|||
|
|
|||
|
```rust,ignore
|
|||
|
let name = Some(String::from("Bors"));
|
|||
|
|
|||
|
match name {
|
|||
|
Some(name) => println!("Found a name: {}", name),
|
|||
|
None => (),
|
|||
|
}
|
|||
|
|
|||
|
// name is moved here. This line will fail to compile:
|
|||
|
println!("name is: {:?}", name);
|
|||
|
```
|
|||
|
|
|||
|
If you'd prefer to bind `name` by reference, use the `ref` keyword:
|
|||
|
|
|||
|
```rust
|
|||
|
let name = Some(String::from("Bors"));
|
|||
|
|
|||
|
match name {
|
|||
|
Some(ref name) => println!("Found a name: {}", name),
|
|||
|
None => (),
|
|||
|
}
|
|||
|
|
|||
|
// name is not moved here; the match only took a reference to its data rather
|
|||
|
// than moving it. This will work:
|
|||
|
println!("name is: {:?}", name);
|
|||
|
```
|
|||
|
|
|||
|
And for a mutable reference, `ref mut`:
|
|||
|
|
|||
|
```rust
|
|||
|
let mut name = Some(String::from("Bors"));
|
|||
|
|
|||
|
match name {
|
|||
|
Some(ref mut name) => *name = String::from("Another name"),
|
|||
|
None => (),
|
|||
|
}
|
|||
|
|
|||
|
// name is not moved here; the match only took a reference to its data rather
|
|||
|
// than moving it
|
|||
|
```
|
|||
|
|
|||
|
## Destructuring
|
|||
|
|
|||
|
Patterns can be used to destructure structs and enums:
|
|||
|
|
|||
|
```rust
|
|||
|
struct Point {
|
|||
|
x: i32,
|
|||
|
y: i32,
|
|||
|
}
|
|||
|
|
|||
|
let origin = Point { x: 0, y: 0 };
|
|||
|
|
|||
|
let Point { x, y } = origin;
|
|||
|
```
|
|||
|
|
|||
|
This brings an `x` and `y` binding into scope, matching the `x` and `y` of
|
|||
|
`origin`. While it can be unusual in `let`, this is the same principle of
|
|||
|
patterns in `match`:
|
|||
|
|
|||
|
```rust
|
|||
|
struct Point {
|
|||
|
x: i32,
|
|||
|
y: i32,
|
|||
|
}
|
|||
|
|
|||
|
let origin = Point { x: 0, y: 0 };
|
|||
|
|
|||
|
match origin {
|
|||
|
Point { x, y } => { }, // x and y are bound here
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
## Shadowing
|
|||
|
|
|||
|
As with all bindings, anything bound by a pattern will shadow bindings
|
|||
|
outside of the binding construct:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = Some(5);
|
|||
|
|
|||
|
match x {
|
|||
|
Some(x) => { }, // x is an i32 here, not an Option<i32>
|
|||
|
None => (),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
## Ignoring bindings
|
|||
|
|
|||
|
We discussed using `_` as a whole pattern to ignore it above, but you can
|
|||
|
also use `_` inside of another pattern to ignore just part of it:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = Some(5);
|
|||
|
|
|||
|
match x {
|
|||
|
Some(_) => println!("got a Some and I don't care what's inside"),
|
|||
|
None => (),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
Or like this:
|
|||
|
|
|||
|
```rust
|
|||
|
let numbers = (2, 4, 8, 16, 32);
|
|||
|
|
|||
|
match numbers {
|
|||
|
(first, _, third, _, fifth) => println!("Some numbers: {}, {}, {}", first, third, fifth),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
If you want, you can use `..` to ignore all of the parts you haven't defined:
|
|||
|
|
|||
|
```rust
|
|||
|
struct Point {
|
|||
|
x: i32,
|
|||
|
y: i32,
|
|||
|
z: i32,
|
|||
|
}
|
|||
|
|
|||
|
let origin = Point { x: 0, y: 0, z: 0 };
|
|||
|
|
|||
|
match origin {
|
|||
|
Point { x, .. } => { }, // y and z are ignored
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
## Ranges
|
|||
|
|
|||
|
You can match a range of values with `...`:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = 5;
|
|||
|
|
|||
|
match x {
|
|||
|
1 ... 5 => println!("one through five"),
|
|||
|
_ => println!("something else"),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
Ranges are usually used with integers or `char`s:
|
|||
|
|
|||
|
```rust
|
|||
|
fn main() {
|
|||
|
let x = 'c';
|
|||
|
|
|||
|
match x {
|
|||
|
'a' ... 'j' => println!("early ASCII letter"),
|
|||
|
'k' ... 'z' => println!("late ASCII letter"),
|
|||
|
_ => println!("something else"),
|
|||
|
}
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
## Guards
|
|||
|
|
|||
|
You can introduce match guards with `if`:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = Some(5);
|
|||
|
|
|||
|
match x {
|
|||
|
Some(x) if x < 5 => println!("less than five: {}", x),
|
|||
|
Some(x) => println!("{}", x),
|
|||
|
None => (),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
If youre using if with multiple patterns, the if applies to both sides:
|
|||
|
|
|||
|
```rust
|
|||
|
let x = 4;
|
|||
|
let y = false;
|
|||
|
|
|||
|
match x {
|
|||
|
4 | 5 if y => println!("yes"),
|
|||
|
_ => println!("no"),
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
This prints `no`, because the if applies to the whole of `4 | 5`, and not to only
|
|||
|
the `5`. In other words, the precedence of if behaves like this:
|
|||
|
|
|||
|
```text
|
|||
|
(4 | 5) if y => ...
|
|||
|
```
|
|||
|
|
|||
|
not this:
|
|||
|
|
|||
|
```text
|
|||
|
4 | (5 if y) => ...
|
|||
|
```
|
|||
|
|
|||
|
## Bindings
|
|||
|
|
|||
|
You can bind values to names with `@`:
|