From 6c63c46817ceccb90aa5e665e56442b8d794e4c8 Mon Sep 17 00:00:00 2001 From: Alex Gotsis Date: Fri, 5 Aug 2022 00:56:52 -0700 Subject: [PATCH] Improve awkward phrasing around the kinds of closures --- src/ch13-01-closures.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ch13-01-closures.md b/src/ch13-01-closures.md index f1ae324354..646204f689 100644 --- a/src/ch13-01-closures.md +++ b/src/ch13-01-closures.md @@ -329,13 +329,13 @@ Using `FnOnce` in the trait bound expresses the constraint that `unwrap_or_else` is only going to call `f` at most one time. 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 the most different kinds -of closures and is as flexible as it can be. +closures implement `FnOnce`, `unwrap_or_else` accepts all 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, +> 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`.