Skip to content

Commit 5190136

Browse files
committed
Simplify note about functions in ch13-01-closures.md
1 parent 668c647 commit 5190136

File tree

1 file changed

+5
-6
lines changed

1 file changed

+5
-6
lines changed

src/ch13-01-closures.md

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -332,12 +332,11 @@ called. If the `Option` is `None`, `f` will be called once. Because all
332332
closures implement `FnOnce`, `unwrap_or_else` accepts the most different kinds
333333
of closures and is as flexible as it can be.
334334

335-
> Note: Functions can implement all three of the `Fn` traits too. If what we
336-
> want to do doesn’t require capturing a value from the environment, we can use
337-
> the name of a function rather than a closure where we need something that
338-
> implements one of the `Fn` traits. For example, on an `Option<Vec<T>>` value,
339-
> we could call `unwrap_or_else(Vec::new)` to get a new, empty vector if the
340-
> value is `None`.
335+
> Note: Functions can be used in place of closures in some cases. For example,
336+
> we could call `unwrap_or_else(Vec::new)` on a value of type `Option<Vec<T>>`.
337+
> If the value is `None`, we would get a new, empty vector. It works because
338+
> functions implement the `Fn` traits just like closures. However, only
339+
> closures can capture variables from the environment, functions cannot do it.
341340
342341
Now let’s look at the standard library method `sort_by_key` defined on slices,
343342
to see how that differs from `unwrap_or_else` and why `sort_by_key` uses

0 commit comments

Comments
 (0)