Rust 程序设计语言 简体中文版

闭包

Closures

Rust 的闭包是可以保存为变量或作为参数传递给其他函数的匿名函数。你可以在一个地方创建闭包，然后在另一个地方调用它以在不同的上下文中求值。与函数不同，闭包可以从定义它们的作用域中捕获值。我们将演示这些闭包特性如何实现代码重用和行为自定义。

Rust’s closures are anonymous functions you can save in a variable or pass as arguments to other functions. You can create the closure in one place and then call the closure elsewhere to evaluate it in a different context. Unlike functions, closures can capture values from the scope in which they’re defined. We’ll demonstrate how these closure features allow for code reuse and behavior customization.

捕获环境

Capturing the Environment

我们首先研究如何使用闭包从定义它们的环境中捕获值以供以后使用。场景如下：我们的 T 恤公司偶尔会向邮件列表中的某人赠送一件独家限量版衬衫作为促销。邮件列表中的人可以有选择地在他们的个人资料中添加他们最喜欢的颜色。如果被选中获得免费衬衫的人设置了他们最喜欢的颜色，他们就会得到那种颜色的衬衫。如果该人没有指定最喜欢的颜色，他们将得到公司目前库存最多的颜色。

We’ll first examine how we can use closures to capture values from the environment they’re defined in for later use. Here’s the scenario: Every so often, our T-shirt company gives away an exclusive, limited-edition shirt to someone on our mailing list as a promotion. People on the mailing list can optionally add their favorite color to their profile. If the person chosen for a free shirt has their favorite color set, they get that color shirt. If the person hasn’t specified a favorite color, they get whatever color the company currently has the most of.

实现这一点的方法有很多。在这个例子中，我们将使用一个名为 ShirtColor 的枚举，它具有 Red 和 Blue 变体（为了简单起见，限制了可用颜色的数量）。我们使用 Inventory 结构体来表示公司的库存，它有一个名为 shirts 的字段，包含一个 Vec<ShirtColor>，表示目前库存中的衬衫颜色。在 Inventory 上定义的 giveaway 方法获取免费衬衫获得者可选的衬衫颜色偏好，并返回该人将获得的衬衫颜色。此设置如示例 13-1 所示。

There are many ways to implement this. For this example, we’re going to use an enum called ShirtColor that has the variants Red and Blue (limiting the number of colors available for simplicity). We represent the company’s inventory with an Inventory struct that has a field named shirts that contains a Vec<ShirtColor> representing the shirt colors currently in stock. The method giveaway defined on Inventory gets the optional shirt color preference of the free-shirt winner, and it returns the shirt color the person will get. This setup is shown in Listing 13-1.

#[derive(Debug, PartialEq, Copy, Clone)]
enum ShirtColor {
    Red,
    Blue,
}

struct Inventory {
    shirts: Vec<ShirtColor>,
}

impl Inventory {
    fn giveaway(&self, user_preference: Option<ShirtColor>) -> ShirtColor {
        user_preference.unwrap_or_else(|| self.most_stocked())
    }

    fn most_stocked(&self) -> ShirtColor {
        let mut num_red = 0;
        let mut num_blue = 0;

        for color in &self.shirts {
            match color {
                ShirtColor::Red => num_red += 1,
                ShirtColor::Blue => num_blue += 1,
            }
        }
        if num_red > num_blue {
            ShirtColor::Red
        } else {
            ShirtColor::Blue
        }
    }
}

fn main() {
    let store = Inventory {
        shirts: vec![ShirtColor::Blue, ShirtColor::Red, ShirtColor::Blue],
    };

    let user_pref1 = Some(ShirtColor::Red);
    let giveaway1 = store.giveaway(user_pref1);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref1, giveaway1
    );

    let user_pref2 = None;
    let giveaway2 = store.giveaway(user_pref2);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref2, giveaway2
    );
}

main 函数中定义的 store 还有两件蓝色衬衫和一件红色衬衫可供此次限量促销分发。我们为一个偏好红色衬衫的用户和一个没有任何偏好的用户调用 giveaway 方法。

The store defined in main has two blue shirts and one red shirt remaining to distribute for this limited-edition promotion. We call the giveaway method for a user with a preference for a red shirt and a user without any preference.

同样，这段代码可以用多种方式实现，在这里，为了专注于闭包，除了使用闭包的 giveaway 方法体之外，我们坚持使用你已经学过的概念。在 giveaway 方法中，我们获取 Option<ShirtColor> 类型的用户偏好作为参数，并在 user_preference 上调用 unwrap_or_else 方法。Option<T> 上的 unwrap_or_else 方法是由标准库定义的。它接受一个参数：一个没有参数并返回类型 T（与 Option<T> 的 Some 变体中存储的类型相同，在本例中为 ShirtColor）的值的闭包。如果 Option<T> 是 Some 变体，unwrap_or_else 返回 Some 中的值。如果 Option<T> 是 None 变体，unwrap_or_else 会调用闭包并返回闭包返回的值。

Again, this code could be implemented in many ways, and here, to focus on closures, we’ve stuck to concepts you’ve already learned, except for the body of the giveaway method that uses a closure. In the giveaway method, we get the user preference as a parameter of type Option<ShirtColor> and call the unwrap_or_else method on user_preference. The unwrap_or_else method on Option<T> is defined by the standard library. It takes one argument: a closure without any arguments that returns a value T (the same type stored in the Some variant of the Option<T>, in this case ShirtColor). If the Option<T> is the Some variant, unwrap_or_else returns the value from within the Some. If the Option<T> is the None variant, unwrap_or_else calls the closure and returns the value returned by the closure.

我们将闭包表达式 || self.most_stocked() 指定为 unwrap_or_else 的参数。这是一个本身不带参数的闭包（如果闭包有参数，它们将出现在两个竖线之间）。闭包体调用 self.most_stocked()。我们在这里定义闭包，如果需要结果，unwrap_or_else 的实现稍后将对闭包求值。

We specify the closure expression || self.most_stocked() as the argument to unwrap_or_else. This is a closure that takes no parameters itself (if the closure had parameters, they would appear between the two vertical pipes). The body of the closure calls self.most_stocked(). We’re defining the closure here, and the implementation of unwrap_or_else will evaluate the closure later if the result is needed.

运行这段代码会打印以下内容：

Running this code prints the following:

$ cargo run
   Compiling shirt-company v0.1.0 (file:///projects/shirt-company)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/shirt-company`
The user with preference Some(Red) gets Red
The user with preference None gets Blue

这里一个有趣的方面是我们传递了一个在当前 Inventory 实例上调用 self.most_stocked() 的闭包。标准库不需要了解我们定义的 Inventory 或 ShirtColor 类型，也不需要了解我们在这个场景中想要使用的逻辑。闭包捕获了对 self Inventory 实例的不可变引用，并将其与我们指定的代码一起传递给 unwrap_or_else 方法。另一方面，函数无法以这种方式捕获其环境。

One interesting aspect here is that we’ve passed a closure that calls self.most_stocked() on the current Inventory instance. The standard library didn’t need to know anything about the Inventory or ShirtColor types we defined, or the logic we want to use in this scenario. The closure captures an immutable reference to the self Inventory instance and passes it with the code we specify to the unwrap_or_else method. Functions, on the other hand, are not able to capture their environment in this way.

推导并注解闭包类型

Inferring and Annotating Closure Types

函数和闭包之间还有更多区别。闭包通常不需要像 fn 函数那样让你注解参数或返回值的类型。函数需要类型注解，因为类型是暴露给用户的显式接口的一部分。严谨地定义这个接口对于确保每个人都对函数使用和返回什么类型的值达成一致非常重要。另一方面，闭包并不用于像这样暴露的接口：它们存储在变量中，在使用它们时无需命名它们并将其暴露给我们库的用户。

There are more differences between functions and closures. Closures don’t usually require you to annotate the types of the parameters or the return value like fn functions do. Type annotations are required on functions because the types are part of an explicit interface exposed to your users. Defining this interface rigidly is important for ensuring that everyone agrees on what types of values a function uses and returns. Closures, on the other hand, aren’t used in an exposed interface like this: They’re stored in variables, and they’re used without naming them and exposing them to users of our library.

闭包通常很短，并且仅在狭窄的上下文中有意义，而不是在任何任意场景中。在这些受限的上下文中，编译器可以推导参数的类型和返回类型，类似于它能够推导大多数变量的类型的方式（在极少数情况下，编译器也需要闭包类型注解）。

Closures are typically short and relevant only within a narrow context rather than in any arbitrary scenario. Within these limited contexts, the compiler can infer the types of the parameters and the return type, similar to how it’s able to infer the types of most variables (there are rare cases where the compiler needs closure type annotations too).

与变量一样，如果我们想要增加显式性和清晰度，我们可以添加类型注解，代价是比绝对必要的代码更繁琐。为闭包注解类型看起来像示例 13-2 中所示的定义。在这个例子中，我们定义了一个闭包并将其存储在一个变量中，而不是像在示例 13-1 中那样在传递参数的地方定义闭包。

As with variables, we can add type annotations if we want to increase explicitness and clarity at the cost of being more verbose than is strictly necessary. Annotating the types for a closure would look like the definition shown in Listing 13-2. In this example, we’re defining a closure and storing it in a variable rather than defining the closure in the spot we pass it as an argument, as we did in Listing 13-1.

use std::thread;
use std::time::Duration;

fn generate_workout(intensity: u32, random_number: u32) {
    let expensive_closure = |num: u32| -> u32 {
        println!("calculating slowly...");
        thread::sleep(Duration::from_secs(2));
        num
    };

    if intensity < 25 {
        println!("Today, do {} pushups!", expensive_closure(intensity));
        println!("Next, do {} situps!", expensive_closure(intensity));
    } else {
        if random_number == 3 {
            println!("Take a break today! Remember to stay hydrated!");
        } else {
            println!(
                "Today, run for {} minutes!",
                expensive_closure(intensity)
            );
        }
    }
}

fn main() {
    let simulated_user_specified_value = 10;
    let simulated_random_number = 7;

    generate_workout(simulated_user_specified_value, simulated_random_number);
}

添加类型注解后，闭包的语法看起来与函数的语法更加相似。为了进行比较，这里我们定义了一个将其参数加 1 的函数和一个具有相同行为的闭包。我们添加了一些空格来对齐相关部分。这说明了闭包语法如何与函数语法相似，除了竖线的使用和可选语法的数量：

With type annotations added, the syntax of closures looks more similar to the syntax of functions. Here, we define a function that adds 1 to its parameter and a closure that has the same behavior, for comparison. We’ve added some spaces to line up the relevant parts. This illustrates how closure syntax is similar to function syntax except for the use of pipes and the amount of syntax that is optional:

fn  add_one_v1   (x: u32) -> u32 { x + 1 }
let add_one_v2 = |x: u32| -> u32 { x + 1 };
let add_one_v3 = |x|             { x + 1 };
let add_one_v4 = |x|               x + 1  ;

第一行显示了一个函数定义，第二行显示了一个完全注解的闭包定义。在第三行中，我们从闭包定义中删除了类型注解。在第四行中，我们删除了花括号，因为闭包体只有一个表达式，所以它们是可选的。这些都是有效的定义，在调用时会产生相同的行为。add_one_v3 和 add_one_v4 行需要对闭包求值才能编译，因为类型将从其用法中推导出来。这类似于 let v = Vec::new(); 需要类型注解或插入某种类型的值到 Vec 中，Rust 才能推导类型。

The first line shows a function definition and the second line shows a fully annotated closure definition. In the third line, we remove the type annotations from the closure definition. In the fourth line, we remove the brackets, which are optional because the closure body has only one expression. These are all valid definitions that will produce the same behavior when they’re called. The add_one_v3 and add_one_v4 lines require the closures to be evaluated to be able to compile because the types will be inferred from their usage. This is similar to let v = Vec::new(); needing either type annotations or values of some type to be inserted into the Vec for Rust to be able to infer the type.

对于闭包定义，编译器将为其每个参数和返回值推导一个具体类型。例如，示例 13-3 展示了一个简单的闭包定义，它只是返回作为参数接收的值。除了用于本例之外，这个闭包没什么用处。请注意，我们没有在定义中添加任何类型注解。由于没有类型注解，我们可以使用任何类型调用闭包，我们在这里第一次使用了 String。如果我们随后尝试使用整数调用 example_closure，我们将得到一个错误。

For closure definitions, the compiler will infer one concrete type for each of their parameters and for their return value. For instance, Listing 13-3 shows the definition of a short closure that just returns the value it receives as a parameter. This closure isn’t very useful except for the purposes of this example. Note that we haven’t added any type annotations to the definition. Because there are no type annotations, we can call the closure with any type, which we’ve done here with String the first time. If we then try to call example_closure with an integer, we’ll get an error.

fn main() {
    let example_closure = |x| x;

    let s = example_closure(String::from("hello"));
    let n = example_closure(5);
}

编译器给出了这个错误：

The compiler gives us this error:

$ cargo run
   Compiling closure-example v0.1.0 (file:///projects/closure-example)
error[E0308]: mismatched types
 --> src/main.rs:5:29
  |
5 |     let n = example_closure(5);
  |             --------------- ^ expected `String`, found integer
  |             |
  |             arguments to this function are incorrect
  |
note: expected because the closure was earlier called with an argument of type `String`
 --> src/main.rs:4:29
  |
4 |     let s = example_closure(String::from("hello"));
  |             --------------- ^^^^^^^^^^^^^^^^^^^^^ expected because this argument is of type `String`
  |             |
  |             in this closure call
note: closure parameter defined here
 --> src/main.rs:2:28
  |
2 |     let example_closure = |x| x;
  |                            ^
help: try using a conversion method
  |
5 |     let n = example_closure(5.to_string());
  |                              ++++++++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `closure-example` (bin "closure-example") due to 1 previous error

我们第一次使用 String 值调用 example_closure 时，编译器推导 x 的类型和闭包的返回类型为 String。这些类型随后被锁定在 example_closure 的闭包中，下次我们尝试在同一个闭包中使用不同类型时，就会得到一个类型错误。

The first time we call example_closure with the String value, the compiler infers the type of x and the return type of the closure to be String. Those types are then locked into the closure in example_closure, and we get a type error when we next try to use a different type with the same closure.

捕获引用或移动所有权

Capturing References or Moving Ownership

闭包可以通过三种方式从其环境中捕获值，这直接对应于函数获取参数的三种方式：不可变借用、可变借用和获取所有权。闭包将根据函数体对捕获的值所做的操作来决定使用哪种方式。

Closures can capture values from their environment in three ways, which directly map to the three ways a function can take a parameter: borrowing immutably, borrowing mutably, and taking ownership. The closure will decide which of these to use based on what the body of the function does with the captured values.

在示例 13-4 中，我们定义了一个捕获名为 list 的 vector 的不可变引用的闭包，因为它只需要一个不可变引用来打印值。

In Listing 13-4, we define a closure that captures an immutable reference to the vector named list because it only needs an immutable reference to print the value.

fn main() {
    let list = vec![1, 2, 3];
    println!("Before defining closure: {list:?}");

    let only_borrows = || println!("From closure: {list:?}");

    println!("Before calling closure: {list:?}");
    only_borrows();
    println!("After calling closure: {list:?}");
}

这个例子也说明了变量可以绑定到闭包定义，稍后我们可以通过使用变量名和括号来调用闭包，就像变量名是一个函数名一样。

This example also illustrates that a variable can bind to a closure definition, and we can later call the closure by using the variable name and parentheses as if the variable name were a function name.

因为我们可以同时对 list 进行多个不可变引用，所以 list 在闭包定义之前、在闭包定义之后但在调用闭包之前，以及在调用闭包之后，仍然可以从代码中访问。这段代码编译、运行并打印：

Because we can have multiple immutable references to list at the same time, list is still accessible from the code before the closure definition, after the closure definition but before the closure is called, and after the closure is called. This code compiles, runs, and prints:

$ cargo run
   Compiling closure-example v0.1.0 (file:///projects/closure-example)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/closure-example`
Before defining closure: [1, 2, 3]
Before calling closure: [1, 2, 3]
From closure: [1, 2, 3]
After calling closure: [1, 2, 3]

接下来，在示例 13-5 中，我们修改闭包体，使其向 list vector 添加一个元素。闭包现在捕获了一个可变引用。

Next, in Listing 13-5, we change the closure body so that it adds an element to the list vector. The closure now captures a mutable reference.

fn main() {
    let mut list = vec![1, 2, 3];
    println!("Before defining closure: {list:?}");

    let mut borrows_mutably = || list.push(7);

    borrows_mutably();
    println!("After calling closure: {list:?}");
}

这段代码编译、运行并打印：

This code compiles, runs, and prints:

$ cargo run
   Compiling closure-example v0.1.0 (file:///projects/closure-example)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/closure-example`
Before defining closure: [1, 2, 3]
After calling closure: [1, 2, 3, 7]

请注意，在 borrows_mutably 闭包的定义和调用之间不再有 println!：当定义 borrows_mutably 时，它捕获了对 list 的可变引用。在调用闭包之后我们不再使用该闭包，因此可变借用结束。在闭包定义和闭包调用之间，不允许进行打印的不可变借用，因为当存在可变借用时，不允许进行任何其他借用。尝试在那里添加一个 println! 看看你会得到什么错误信息！

Note that there’s no longer a println! between the definition and the call of the borrows_mutably closure: When borrows_mutably is defined, it captures a mutable reference to list. We don’t use the closure again after the closure is called, so the mutable borrow ends. Between the closure definition and the closure call, an immutable borrow to print isn’t allowed, because no other borrows are allowed when there’s a mutable borrow. Try adding a println! there to see what error message you get!

如果你想强制闭包获取它在环境中所使用的值的所有权，即使闭包体并不严格需要所有权，你可以在参数列表之前使用 move 关键字。

If you want to force the closure to take ownership of the values it uses in the environment even though the body of the closure doesn’t strictly need ownership, you can use the move keyword before the parameter list.

这种技术在将闭包传递给新线程以移动数据使其归新线程所有时最有用。我们将在第 16 章讨论并发时详细讨论线程以及为什么要使用它们，但现在，让我们简要探讨一下使用需要 move 关键字的闭包生成新线程。示例 13-6 显示了修改后的示例 13-4，用于在新线程而不是主线程中打印 vector。

This technique is mostly useful when passing a closure to a new thread to move the data so that it’s owned by the new thread. We’ll discuss threads and why you would want to use them in detail in Chapter 16 when we talk about concurrency, but for now, let’s briefly explore spawning a new thread using a closure that needs the move keyword. Listing 13-6 shows Listing 13-4 modified to print the vector in a new thread rather than in the main thread.

use std::thread;

fn main() {
    let list = vec![1, 2, 3];
    println!("Before defining closure: {list:?}");

    thread::spawn(move || println!("From thread: {list:?}"))
        .join()
        .unwrap();
}

我们派生一个新线程，给该线程一个闭包作为参数运行。闭包体打印出列表。在示例 13-4 中，闭包仅使用不可变引用捕获 list，因为这是打印它所需的对 list 的最小访问权限。在这个例子中，即使闭包体仍然只需要一个不可变引用，我们也需要通过在闭包定义开头放置 move 关键字来指定应该将 list 移动到闭包中。如果主线程在对新线程调用 join 之前执行了更多操作，新线程可能会在主线程的其余部分完成之前完成，或者主线程可能会先完成。如果主线程保留了 list 的所有权但在新线程结束前结束并释放了 list，则线程中的不可变引用将失效。因此，编译器要求将 list 移动到提供给新线程的闭包中，以便引用有效。尝试删除 move 关键字或在定义闭包后在主线程中使用 list，看看你会得到什么编译器错误！

We spawn a new thread, giving the thread a closure to run as an argument. The closure body prints out the list. In Listing 13-4, the closure only captured list using an immutable reference because that’s the least amount of access to list needed to print it. In this example, even though the closure body still only needs an immutable reference, we need to specify that list should be moved into the closure by putting the move keyword at the beginning of the closure definition. If the main thread performed more operations before calling join on the new thread, the new thread might finish before the rest of the main thread finishes, or the main thread might finish first. If the main thread maintained ownership of list but ended before the new thread and drops list, the immutable reference in the thread would be invalid. Therefore, the compiler requires that list be moved into the closure given to the new thread

so that the reference will be valid. Try removing the move关键字 or using

list in the main thread after the closure is defined to see what compiler errors you get!

将捕获的值移出闭包

Moving Captured Values Out of Closures

一旦闭包从定义它的环境中捕获了引用或捕获了值的所有权（从而影响了什么内容被移动 进 闭包，如果有的话），闭包体中的代码就定义了稍后对闭包求值时引用或值会发生什么（从而影响了什么内容被移 出 闭包，如果有的话）。

Once a closure has captured a reference or captured ownership of a value from the environment where the closure is defined (thus affecting what, if anything, is moved into the closure), the code in the body of the closure defines what happens to the references or values when the closure is evaluated later (thus affecting what, if anything, is moved out of the closure).

闭包体可以执行以下任何操作：将捕获的值移出闭包、修改捕获的值、既不移动也不修改值，或者最初不从环境中捕获任何内容。

A closure body can do any of the following: Move a captured value out of the closure, mutate the captured value, neither move nor mutate the value, or capture nothing from the environment to begin with.

闭包捕获和处理环境中值的方式会影响闭包实现的 trait，而 trait 是函数和结构体指定它们可以使用哪种闭包的方式。根据闭包体处理值的方式，闭包将自动以累加的方式实现这三个 Fn trait 中的一个、两个或全部三个：

The way a closure captures and handles values from the environment affects which traits the closure implements, and traits are how functions and structs can specify what kinds of closures they can use. Closures will automatically implement one, two, or all three of these Fn traits, in an additive fashion, depending on how the closure’s body handles the values:

• FnOnce 适用于可以调用一次的闭包。所有闭包都至少实现此 trait，因为所有闭包都是可以调用的。将捕获的值移出其主体的闭包将仅实现 FnOnce 而不实现任何其他 Fn trait，因为它只能被调用一次。

• FnOnce applies to closures that can be called once. All closures implement at least this trait because all closures can be called. A closure that moves captured values out of its body will only implement FnOnce and none of the other Fn traits because it can only be called once.

• FnMut 适用于不将捕获的值移出主体，但可能会修改捕获的值的闭包。这些闭包可以被多次调用。

• FnMut applies to closures that don’t move captured values out of their body but might mutate the captured values. These closures can be called more than once.

• Fn 适用于既不将捕获的值移出主体也不修改捕获的值的闭包，以及不从环境中捕获任何内容的闭包。这些闭包可以在不修改其环境的情况下多次调用，这在诸如并发多次调用闭包的情况下非常重要。

• Fn applies to closures that don’t move captured values out of their body and don’t mutate captured values, as well as closures that capture nothing from their environment. These closures can be called more than once without mutating their environment, which is important in cases such as calling a closure multiple times concurrently.

让我们看看示例 13-1 中使用的 Option<T> 上的 unwrap_or_else 方法的定义：

Let’s look at the definition of the unwrap_or_else method on Option<T> that used in Listing 13-1:

impl<T> Option<T> {
    pub fn unwrap_or_else<F>(self, f: F) -> T
    where
        F: FnOnce() -> T
    {
        match self {
            Some(x) => x,
            None => f(),
        }
    }
}

回想一下，T 是代表 Option 的 Some 变体中值的类型的泛型。该类型 T 也是 unwrap_or_else 函数的返回类型：例如，在 Option<String> 上调用 unwrap_or_else 的代码将获得一个 String。

Recall that T is the generic type representing the type of the value in the Some variant of an Option. That type T is also the return type of the unwrap_or_else function: Code that calls unwrap_or_else on an Option<String>, for example, will get a String.

接下来，注意 unwrap_or_else 函数具有额外的泛型类型参数 F。F 类型是名为 f 的参数的类型，它是在调用 unwrap_or_else 时提供的闭包。

Next, notice that the unwrap_or_else function has the additional generic type parameter F. The F type is the type of the parameter named f, which is the closure we provide when calling unwrap_or_else.

在泛型 F 上指定的 trait 约束是 FnOnce() -> T，这意味着 F 必须能够被调用一次，不带参数并返回 T。在 trait 约束中使用 FnOnce 表达了 unwrap_or_else 调用 f 不会超过一次的约束。在 unwrap_or_else 的主体中，我们可以看到如果 Option 是 Some，则不会调用 f。如果 Option 是 None，f 将被调用一次。因为所有闭包都实现 FnOnce，所以 unwrap_or_else 接受所有三种闭包，并且具有最大的灵活性。

The trait bound specified on the generic type F is FnOnce() -> T, which means F must be able to be called once, take no arguments, and return a T. Using FnOnce in the trait bound expresses the constraint that unwrap_or_else will not call f more than once. In the body of unwrap_or_else, we can see that if the Option is Some, f won’t be called. If the Option is None, f will be called once. Because all closures implement FnOnce, unwrap_or_else accepts all three kinds of closures and is as flexible as it can be.

注意：如果我们想要做的操作不需要从环境中捕获值，在需要实现 Fn trait 的地方，我们可以使用函数的名称而不是闭包。例如，在 Option<Vec<T>> 值上，我们可以调用 unwrap_or_else(Vec::new)，如果值为 None，则获取一个新的空 vector。编译器会自动为函数定义实现任何适用的 Fn trait。

Note: If what we want to do doesn’t require capturing a value from the environment, we can use the name of a function rather than a closure where we need something that implements one of the Fn traits. For example, on an Option<Vec<T>> value, we could call unwrap_or_else(Vec::new) to get a new, empty vector if the value is None. The compiler automatically implements whichever of the Fn traits is applicable for a function definition.

现在让我们看看在切片上定义的标准库方法 sort_by_key，看看它与 unwrap_or_else 有何不同，以及为什么 sort_by_key 为 trait 约束使用 FnMut 而不是 FnOnce。闭包获取一个参数，形式是对当前正在考虑的切片中项目的引用，并返回一个可以排序的 K 类型的值。当你想要根据每个项目的特定属性对切片进行排序时，此函数非常有用。在示例 13-7 中，我们有一个 Rectangle 实例列表，并使用 sort_by_key 按其 width 属性从小到大对它们进行排序。

Now let’s look at the standard library method sort_by_key, defined on slices, to see how that differs from unwrap_or_else and why sort_by_key uses FnMut instead of FnOnce for the trait bound. The closure gets one argument in the form of a reference to the current item in the slice being considered, and it returns a value of type K that can be ordered. This function is useful when you want to sort a slice by a particular attribute of each item. In Listing 13-7, we have a list of Rectangle instances, and we use sort_by_key to order them by their width attribute from low to high.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let mut list = [
        Rectangle { width: 10, height: 1 },
        Rectangle { width: 3, height: 5 },
        Rectangle { width: 7, height: 12 },
    ];

    list.sort_by_key(|r| r.width);
    println!("{list:#?}");
}

这段代码打印：

This code prints:

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.41s
     Running `target/debug/rectangles`
[
    Rectangle {
        width: 3,
        height: 5,
    },
    Rectangle {
        width: 7,
        height: 12,
    },
    Rectangle {
        width: 10,
        height: 1,
    },
]

sort_by_key 被定义为接受 FnMut 闭包的原因是它会多次调用闭包：切片中的每个项目调用一次。闭包 |r| r.width 既不从环境中捕获、修改也不移出任何内容，因此它满足 trait 约束要求。

The reason sort_by_key is defined to take an FnMut closure is that it calls the closure multiple times: once for each item in the slice. The closure |r| r.width doesn’t capture, mutate, or move anything out from its environment, so it meets the trait bound requirements.

相比之下，示例 13-8 显示了一个仅实现 FnOnce trait 的闭包示例，因为它从环境中移出了一个值。编译器不允许我们将此闭包与 sort_by_key 一起使用。

In contrast, Listing 13-8 shows an example of a closure that implements just the FnOnce trait, because it moves a value out of the environment. The compiler won’t let us use this closure with sort_by_key.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let mut list = [
        Rectangle { width: 10, height: 1 },
        Rectangle { width: 3, height: 5 },
        Rectangle { width: 7, height: 12 },
    ];

    let mut sort_operations = vec![];
    let value = String::from("closure called");

    list.sort_by_key(|r| {
        sort_operations.push(value);
        r.width
    });
    println!("{list:#?}");
}

这是一种人为设计的、复杂的方法（而且行不通），试图在对 list 排序时统计 sort_by_key 调用闭包的次数。这段代码试图通过将 value（来自闭包环境的 String）推入 sort_operations vector 来进行计数。闭包捕获 value，然后通过将 value 的所有权转移到 sort_operations vector 来将 value 移出闭包。此闭包只能调用一次；尝试第二次调用它将不起作用，因为 value 将不再在环境中，无法再次推入 sort_operations！因此，此闭包仅实现 FnOnce。当我们尝试编译此代码时，我们会得到这个错误，即 value 不能被移出闭包，因为闭包必须实现 FnMut：

This is a contrived, convoluted way (that doesn’t work) to try to count the number of times sort_by_key calls the closure when sorting list. This code attempts to do this counting by pushing value—a String from the closure’s environment—into the sort_operations vector. The closure captures value and then moves value out of the closure by transferring ownership of value to the sort_operations vector. This closure can be called once; trying to call it a second time wouldn’t work, because value would no longer be in the environment to be pushed into sort_operations again! Therefore, this closure only implements FnOnce. When we try to compile this code, we get this error that value can’t be moved out of the closure because the closure must implement FnMut:

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
error[E0507]: cannot move out of `value`, a captured variable in an `FnMut` closure
  --> src/main.rs:18:30
   |
15 |     let value = String::from("closure called");
   |         -----   ------------------------------ move occurs because `value` has type `String`, which does not implement the `Copy` trait
   |         |
   |         captured outer variable
16 |
17 |     list.sort_by_key(|r| {
   |                      --- captured by this `FnMut` closure
18 |         sort_operations.push(value);
   |                              ^^^^^ `value` is moved here
   |
help: consider cloning the value if the performance cost is acceptable
   |
18 |         sort_operations.push(value.clone());
   |                                   ++++++++

For more information about this error, try `rustc --explain E0507`.
error: could not compile `rectangles` (bin "rectangles") due to 1 previous error

该错误指向闭包体中将 value 移出环境的那一行。要修复此问题，我们需要更改闭包体，使其不将值移出环境。在环境中保留一个计数器并在闭包体中增加其值是计算闭包调用次数的更直接的方法。示例 13-9 中的闭包可以与 sort_by_key 配合使用，因为它仅捕获对 num_sort_operations 计数器的可变引用，因此可以被多次调用。

The error points to the line in the closure body that moves value out of the environment. To fix this, we need to change the closure body so that it doesn’t move values out of the environment. Keeping a counter in the environment and incrementing its value in the closure body is a more straightforward way to count the number of times the closure is called. The closure in Listing 13-9 works with sort_by_key because it is only capturing a mutable reference to the num_sort_operations counter and can therefore be called more than once.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let mut list = [
        Rectangle { width: 10, height: 1 },
        Rectangle { width: 3, height: 5 },
        Rectangle { width: 7, height: 12 },
    ];

    let mut num_sort_operations = 0;
    list.sort_by_key(|r| {
        num_sort_operations += 1;
        r.width
    });
    println!("{list:#?}, sorted in {num_sort_operations} operations");
}

在定义或使用利用闭包的函数或类型时，Fn trait 非常重要。在下一节中，我们将讨论迭代器。许多迭代器方法都接受闭包参数，因此在我们继续学习时，请记住这些闭包的细节！

The Fn traits are important when defining or using functions or types that make use of closures. In the next section, we’ll discuss iterators. Many iterator methods take closure arguments, so keep these closure details in mind as we continue!