From 5190136589b7c6fdb8237e4e2429294621a47bcb Mon Sep 17 00:00:00 2001 From: Pavel Roskin Date: Thu, 13 Jul 2023 16:47:33 -0700 Subject: [PATCH] Simplify note about functions in ch13-01-closures.md --- src/ch13-01-closures.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/ch13-01-closures.md b/src/ch13-01-closures.md index f1ae324354..e4989eb5c3 100644 --- a/src/ch13-01-closures.md +++ b/src/ch13-01-closures.md @@ -332,12 +332,11 @@ called. If the `Option` is `None`, `f` will be called once. Because all closures implement `FnOnce`, `unwrap_or_else` accepts the most different kinds of closures and is as flexible as it can be. -> Note: Functions can implement all three of the `Fn` traits too. 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>` value, -> we could call `unwrap_or_else(Vec::new)` to get a new, empty vector if the -> value is `None`. +> Note: Functions can be used in place of closures in some cases. For example, +> we could call `unwrap_or_else(Vec::new)` on a value of type `Option>`. +> If the value is `None`, we would get a new, empty vector. It works because +> functions implement the `Fn` traits just like closures. However, only +> closures can capture variables from the environment, functions cannot do it. 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