community fixups

data.md

@@ -88,7 +88,7 @@ struct Foo<u32, u16> {
 }
 ```
 
-The former case quite simply wastes space. An optimal use of space therefore requires
+The latter case quite simply wastes space. An optimal use of space therefore requires
 different monomorphizations to *have different field orderings*.
 
 **Note: this is a hypothetical optimization that is not yet implemented in Rust 1.0.0**

lifetimes.md

@@ -247,11 +247,11 @@ Of course, it might be bounded by the *wrong* lifetime, but this will usually
 just cause a compiler error, rather than allow memory safety to be trivially
 violated.
 
-Within a function, bounding lifetimes is more error-prone. The safest route
+Within a function, bounding lifetimes is more error-prone. The safest and easiest
-is to just use a small function to ensure the lifetime is bound. However if
+way to bound a lifetime is to return it from a function with a bound lifetime.
-this is unacceptable, the reference can be placed in a location with a specific
+However if this is unacceptable, the reference can be placed in a location with
-lifetime. Unfortunately it's impossible to name all lifetimes involved in a
+a specific lifetime. Unfortunately it's impossible to name all lifetimes involved
-function. To get around this, you can in principle use `copy_lifetime`, though
+in a function. To get around this, you can in principle use `copy_lifetime`, though
 these are unstable due to their awkward nature and questionable utility.
 
 
@@ -425,7 +425,7 @@ must be invariant to avoid lifetime smuggling.
 
 `Fn` is the most confusing case, largely because contravariance is easily the
 most confusing kind of variance, and basically never comes up. To understand it,
-consider a function that *takes* a function `len` that takes a function `F`.
+consider a function `len` that takes a function `F`.
 
 ```rust
 fn len<F>(func: F) -> usize
@@ -435,8 +435,8 @@ fn len<F>(func: F) -> usize
 }
 ```
 
-We require that F is a Fn that can take an `&'static str` and print a usize. Now
+We require that F is a Fn that can take an `&'static str` and returns a usize. Now
-say we have a function that can take an `&'a str` (for *some* 'a). Such a function actually
+say we have a function that can take an `&'a str` (for *some* `'a`). Such a function actually
 accepts *more* inputs, since `&'static str` is a subtype of `&'a str`. Therefore
 `len` should happily accept such a function!
 
@@ -643,8 +643,8 @@ trait Iterator {
 Given this definition, Self::Item has *no* connection to `self`. This means
 that we can call `next` several times in a row, and hold onto all the results
 *concurrently*. This is perfectly fine for by-value iterators, which have exactly
-these semantics. It's also actually fine for shared references, as it's perfectly
+these semantics. It's also actually fine for shared references, as they admit
-fine to grab a huge pile of shared references to the same thing (although the
+arbitrarily many references to the same thing (although the
 iterator needs to be a separate object from the thing being shared). But mutable
 references make this a mess. At first glance, they might seem completely
 incompatible with this API, as it would produce multiple mutable references to