address review concerns

This commit is contained in:
Craig Hills 2015-10-06 10:30:33 -04:00
parent a78a874ebb
commit 7895ec2d57

View File

@ -1,9 +1,9 @@
% Closures
Sometimes it is useful to wrap up a function and free variables for better
clarity and reuse. The _free variables_ that can be used come from the
enclosing scope and are "closed over" when used in the function. From this, we
get the name "closures" and Rust provides a really great implementation of
Sometimes it is useful to wrap up a function and _free variables_ for better
clarity and reuse. The free variables that can be used come from the
enclosing scope and are closed over when used in the function. From this, we
get the name closures and Rust provides a really great implementation of
them, as well see.
# Syntax
@ -46,10 +46,11 @@ assert_eq!(2, plus_one(1));
```
But we dont have to. Why is this? Basically, it was chosen for ergonomic
reasons. While specifying the full type for named functions is helpful with
things like documentation and type inference, types within closures are rarely
documented since theyre anonymous, and they dont cause the kinds of
error-at-a-distance problems that inferring named function types can.
reasons. While specifying the full type for named functions is helpful with
things like documentation and type inference, the full type signatures of
closures are rarely documented since theyre anonymous, and they dont cause
the kinds of error-at-a-distance problems that inferring named function types
can.
The second is that the syntax is similar, but a bit different. Ive added
spaces here for easier comparison:
@ -65,7 +66,7 @@ Small differences, but theyre similar.
# Closures and their environment
The environment for a closure can include bindings from its enclosing scope in
addition to parameters and local bindings. It looks like this:
addition to parameters and local bindings. It looks like this:
```rust
let num = 5;
@ -454,7 +455,7 @@ autogenerated name.
The error also points out that the return type is expected to be a reference,
but what we are trying to return is not. Further, we cannot directly assign a
`'static` lifetime to an object. So we'll take a different approach and return
a "trait object" by `Box`ing up the `Fn`. This _almost_ works:
a trait object by `Box`ing up the `Fn`. This _almost_ works:
```rust,ignore
fn factory() -> Box<Fn(i32) -> i32> {