Skip to content

Commit

Permalink
Improve awkward phrasing around the kinds of closures
Browse files Browse the repository at this point in the history
  • Loading branch information
agotsis committed Aug 5, 2022
1 parent 36383b4 commit 6c63c46
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions src/ch13-01-closures.md
Original file line number Diff line number Diff line change
Expand Up @@ -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<Vec<T>>` value,
> 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`.
Expand Down

0 comments on commit 6c63c46

Please sign in to comment.