Improved Ch13

src/Ch13_Functional_Language_Features_Iterators_and_Closures.md

@@ -111,13 +111,13 @@ $ cargo run                                                         lennyp@vm-ma
 这里有个有趣的地方，即这里曾传递了一个调用了在当前 `Inventory` 实例上的 `self.most_stocked()` 的闭包。标准库并不需要明白有关这里所定义的 `Inventory` 或 `ShirtColor` 的任何事情，或者在此场景下这里要运用的那些逻辑。这个闭包捕获了到 `self` 这个 `Inventory` 实例的一个不可变引用，并将该不可变引用，传递给这里指定给那个 `unwrap_or_else` 方法的代码。与之相反，函数是无法以这种方式，捕获到他们的环境的（the closure captures an immutable reference to the `self` `Inventory` instance and pass it with the code we specify to the `unwrap_or_else` method. Functions, on the other hand, are not able to capture their environment in this way）。
 
 
-### 闭包的类型推断与类型注解
+### 闭包的类型推断与注解
 
 **Closure Type Inference and Annotation**
 
-函数与闭包之间，还有别的一些区别。闭包通常不要求像 `fn` 函数那样，注解参数或返回值的类型。之所以在函数上要求类型注解，是因为类型是暴露给用户的显式接口的组成部分。严格定义这种接口，对于确保所有人，在某个函数用到与返回的值类型上，达成一致尤为重要。与此相反，闭包则不是用在像这样暴露出的接口中：闭包存储在变量中，并在无需命名及暴露给库用户下而被使用。
+函数与闭包之间，还有别的一些区别。闭包通常不要求咱们像 `fn` 函数那样，注解参数或返回值的类型。之所以在函数上要求类型注解，是因为类型是暴露给用户的显式接口的一部分。硬性要求定义出这种接口，对于确保所有人，在某个函数用到与返回的值类型上，达成一致尤为重要。而另一方面的闭包，则不是用在像这样的暴露接口中：他们被存储于变量中，而在无需对其命名及暴露给库用户下被用到。
 
-闭包通常是短小的，并仅在较窄的上下文，而非在任何情况下都有意义。有了执行受限条件，那么编译器就可以推断出参数与返回值的类型，类似于编译器能够推断出绝大多数变量的类型那样（同样有极少情况下，编译器需要闭包的类型注解）。
+闭包通常是短小的，并仅在较窄的上下文里，而非任何场景下都有意义。在这些受限的条件下，编译器就可以推断出参数与返回值的类型，类似于其能够推断出绝大多数变量类型的方式（同样也有极少数编译器需要闭包类型注解的情况）。
 
 与变量一样，在想要提升明确性与清楚时，是可以添加类型的，只不过要付出相比严格必要更多的繁琐代价。对闭包的类型进行注解，看起来会与下面清单 13-2 中所给出的定义一样。在此示例中，这里定义了一个闭包，并将其存储在一个变量中，而非清单 13-1 中所做的那样，把闭包定义在将其作为参数加以传递的地方。