Wrap to 80 characters

Author: dtolnay

src/about.md

@@ -1,23 +1,21 @@
 # Rust API Guidelines
 
-This is a set of recommendations on how to design and present APIs for
-the Rust programming language. They are authored largely by the Rust
-library team, based on experiences building the Rust standard library
-and other crates in the Rust ecosystem.
+This is a set of recommendations on how to design and present APIs for the Rust
+programming language. They are authored largely by the Rust library team, based
+on experiences building the Rust standard library and other crates in the Rust
+ecosystem.
 
-These are only guidelines, some more firm than others. In some cases
-they are vague and still in development. Rust crate authors should
-consider them as a set of important considerations in the development
-of idiomatic and interoperable Rust libraries, to use as they see
-fit. These guidelines should not in any way be considered a mandate
-that crate authors must follow, though they may find that crates that
-conform well to these guidelines integrate better with the existing
-crate ecosystem than those that do not.
+These are only guidelines, some more firm than others. In some cases they are
+vague and still in development. Rust crate authors should consider them as a set
+of important considerations in the development of idiomatic and interoperable
+Rust libraries, to use as they see fit. These guidelines should not in any way
+be considered a mandate that crate authors must follow, though they may find
+that crates that conform well to these guidelines integrate better with the
+existing crate ecosystem than those that do not.
 
-This books is organized in two parts: the concise [checklist] of all
-individual guidelines, suitable for quick scanning during crate
-reviews; and topical chapters containing explanations of the
-guidelines in detail.
+This books is organized in two parts: the concise [checklist] of all individual
+guidelines, suitable for quick scanning during crate reviews; and topical
+chapters containing explanations of the guidelines in detail.
 
 If you are interested in contributing to the API guidelines, check out
 [contributing.md] and join our [Gitter channel].

src/future-proofing.md

@@ -125,10 +125,10 @@ pub fn my_transform<I: Iterator>(input: I) -> impl Iterator<Item = (usize, I::It
 <a id="c-struct-bounds"></a>
 ## Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
 
-Generic data structures should not use trait bounds that can be derived or don't otherwise
-add semantic value.
-Each trait in the `derive` attribute will be expanded into a separate `impl` block that
-only applies to generic arguments that implement that trait.
+Generic data structures should not use trait bounds that can be derived or don't
+otherwise add semantic value. Each trait in the `derive` attribute will be
+expanded into a separate `impl` block that only applies to generic arguments
+that implement that trait.
 
 ```rust
 // Prefer this:
@@ -141,9 +141,8 @@ struct Bad<T: Clone + Debug + PartialEq> { /* ... */ }
 ```
 
 Duplicating derived traits as bounds on `Bad` is unnecessary and a
-backwards-compatibiliity hazard.
-To illustrate this point, consider deriving `PartialOrd` on the structures in the
-previous example:
+backwards-compatibiliity hazard. To illustrate this point, consider deriving
+`PartialOrd` on the structures in the previous example:
 
 ```rust
 // Non-breaking change:
@@ -155,10 +154,10 @@ struct Good<T> { /* ... */ }
 struct Bad<T: Clone + Debug + PartialEq + PartialOrd> { /* ... */ }
 ```
 
-Generally speaking, adding a trait bound to a data structure is a breaking change
-because every consumer of that structure will need to start satisfying the additional bound.
-Deriving more traits from the standard library using the `derive` attribute is not a
-breaking change.
+Generally speaking, adding a trait bound to a data structure is a breaking
+change because every consumer of that structure will need to start satisfying
+the additional bound. Deriving more traits from the standard library using the
+`derive` attribute is not a breaking change.
 
 The following traits should always be avoided in bounds on data structures:
 
@@ -173,11 +172,10 @@ The following traits should always be avoided in bounds on data structures:
 - `DeserializeOwned`
 
 There's a grey area around other non-derivable trait bounds that aren't strictly
-required by the structure definition, like `Read` or `Write`.
-They may communicate the intented behaviour of the type better in its definition
-but also limits future extensibility.
-Including semantically useful trait bounds on data structures is still less
-problematic than including derivable traits as bounds.
+required by the structure definition, like `Read` or `Write`. They may
+communicate the intented behaviour of the type better in its definition but also
+limits future extensibility. Including semantically useful trait bounds on data
+structures is still less problematic than including derivable traits as bounds.
 
 ### Exceptions
 

src/necessities.md

@@ -44,23 +44,22 @@ impl From<other_crate::Error> for Error {
 <a id="c-permissive"></a>
 ## Crate and its dependencies have a permissive license (C-PERMISSIVE)
 
-The software produced by the Rust project is dual-licensed, under
-either the [MIT] or [Apache 2.0] licenses. Crates that simply need the
-maximum compatibility with the Rust ecosystem are recommended to do
-the same, in the manner described herein. Other options are described
-below.
+The software produced by the Rust project is dual-licensed, under either the
+[MIT] or [Apache 2.0] licenses. Crates that simply need the maximum
+compatibility with the Rust ecosystem are recommended to do the same, in the
+manner described herein. Other options are described below.
 
-These API guidelines do not provide a detailed explanation of Rust's
-license, but there is a small amount said in the [Rust FAQ]. These
-guidelines are concerned with matters of interoperability with Rust,
-and are not comprehensive over licensing options.
+These API guidelines do not provide a detailed explanation of Rust's license,
+but there is a small amount said in the [Rust FAQ]. These guidelines are
+concerned with matters of interoperability with Rust, and are not comprehensive
+over licensing options.
 
 [MIT]: https://github.com/rust-lang/rust/blob/master/LICENSE-MIT
 [Apache 2.0]: https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE
 [Rust FAQ]: https://www.rust-lang.org/en-US/faq.html#why-a-dual-mit-asl2-license
 
-To apply the Rust license to your project, define the `license` field
-in your `Cargo.toml` as:
+To apply the Rust license to your project, define the `license` field in your
+`Cargo.toml` as:
 
 ```toml
 [package]
@@ -91,18 +90,17 @@ for inclusion in the work by you, as defined in the Apache-2.0 license, shall be
 dual licensed as above, without any additional terms or conditions.
 ```
 
-Besides the dual MIT/Apache-2.0 license, another common licensing approach
-used by Rust crate authors is to apply a single permissive license such as
-MIT or BSD. This license scheme is also entirely compatible with Rust's,
-because it imposes the minimal restrictions of Rust's MIT license.
+Besides the dual MIT/Apache-2.0 license, another common licensing approach used
+by Rust crate authors is to apply a single permissive license such as MIT or
+BSD. This license scheme is also entirely compatible with Rust's, because it
+imposes the minimal restrictions of Rust's MIT license.
 
-Crates that desire perfect license compatibility with Rust are not
-recommended to choose only the Apache license. The Apache license,
-though it is a permissive license, imposes restrictions beyond the MIT
-and BSD licenses that can discourage or prevent their use in some
-scenarios, so Apache-only software cannot be used in some situations
-where most of the Rust runtime stack can.
+Crates that desire perfect license compatibility with Rust are not recommended
+to choose only the Apache license. The Apache license, though it is a permissive
+license, imposes restrictions beyond the MIT and BSD licenses that can
+discourage or prevent their use in some scenarios, so Apache-only software
+cannot be used in some situations where most of the Rust runtime stack can.
 
 The license of a crate's dependencies can affect the restrictions on
-distribution of the crate itself, so a permissively-licensed crate
-should generally only depend on permissively-licensed crates.
+distribution of the crate itself, so a permissively-licensed crate should
+generally only depend on permissively-licensed crates.

src/predictability.md

@@ -181,25 +181,21 @@ a type. Sometimes it takes no arguments, as in the examples above. Sometimes it
 does take arguments, like [`Box::new`] which is passed the value to place in the
 `Box`.
 
-Some types' constructors, most notably I/O resource types, use
-distinct naming conventions for their constructors, as in
-[`File::open`], [`Mmap::open`], [`TcpStream::connect`], and
-[`UpdSocket::bind`]. In these cases names are chosen as appropriate
-for the domain.
-
-Often there are multiple ways to construct a type. It's common in
-these cases for secondary constructors to be be suffixed, `_with_foo`,
-as in [`Mmap::open_with_offset`]. If your type has a multiplicity of
-construction options though, consider the builder
-pattern ([C-BUILDER]) instead.
-
-Some constructors are "conversion constructors", methods that create a
-new type from an existing value of a different type. These typically
-have names begining with `from_` as in
-[`std::io::Error::from_raw_os_error`]. Note also though the `From`
-trait ([C-CONV-TRAITS]), which is quite similar. Guidelines for
-writing a `From` implementation vs. writing `from_foo` need further
-examination.
+Some types' constructors, most notably I/O resource types, use distinct naming
+conventions for their constructors, as in [`File::open`], [`Mmap::open`],
+[`TcpStream::connect`], and [`UpdSocket::bind`]. In these cases names are chosen
+as appropriate for the domain.
+
+Often there are multiple ways to construct a type. It's common in these cases
+for secondary constructors to be be suffixed, `_with_foo`, as in
+[`Mmap::open_with_offset`]. If your type has a multiplicity of construction
+options though, consider the builder pattern ([C-BUILDER]) instead.
+
+Some constructors are "conversion constructors", methods that create a new type
+from an existing value of a different type. These typically have names begining
+with `from_` as in [`std::io::Error::from_raw_os_error`]. Note also though the
+`From` trait ([C-CONV-TRAITS]), which is quite similar. Guidelines for writing a
+`From` implementation vs. writing `from_foo` need further examination.
 
 Note that it is common and expected for types to implement both `Default` and a
 `new` constructor. For types that have both, they should have the same behavior.