Skip to content

Commit a5ccba9

Browse files
authored
Merge pull request #3699 from proski/closure-note
Simplify note about functions in ch13-01-closures.md
2 parents 1521e4e + 60b198a commit a5ccba9

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

src/ch13-01-closures.md

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

333-
> Note: Functions can implement all three of the `Fn` traits too. If what we
334-
> want to do doesn’t require capturing a value from the environment, we can use
335-
> the name of a function rather than a closure where we need something that
336-
> implements one of the `Fn` traits. For example, on an `Option<Vec<T>>` value,
337-
> we could call `unwrap_or_else(Vec::new)` to get a new, empty vector if the
338-
> value is `None`.
333+
> Note: If what we want to do doesn’t require capturing a value from the
334+
> environment, we can use the name of a function rather than a closure. For
335+
> example, we could call `unwrap_or_else(Vec::new)` on a `Option<Vec<T>>` value
336+
> to get a new, empty vector if the value is `None`. The compiler automatically
337+
> implements whichever of the `Fn` traits is applicable for a function
338+
> definition.
339339
340340
Now let’s look at the standard library method `sort_by_key` defined on slices,
341341
to see how that differs from `unwrap_or_else` and why `sort_by_key` uses

0 commit comments

Comments
 (0)