revert to the inconsistent paragraph wrapping. · rust-lang/rust@939f267
@@ -2,8 +2,8 @@
22//!
33//! [`Result<T, E>`][`Result`] is the type used for returning and propagating
44//! errors. It is an enum with the variants, [`Ok(T)`], representing success and
5-//! containing a value, and [`Err(E)`], representing error and containing an
6-//! error value.
5+//! success and containing a value, and [`Err(E)`], representing error
6+//! and containing an error value.
77//!
88//! ```
99//! # #[allow(dead_code)]
@@ -14,10 +14,11 @@
1414//! ```
1515//!
1616//! Functions return [`Result`] whenever errors are expected and recoverable. In
17-//! the `std` crate, [`Result`] is most prominently used for
18-//! [I/O](../../std/io/index.html).
17+//! recoverable. In the `std` crate, [`Result`] is most prominently used
18+//! for [I/O](../../std/io/index.html).
1919//!
20-//! A simple function returning [`Result`] might be defined and used like so:
20+//! A simple function returning [`Result`] might be
21+//! defined and used like so:
2122//!
2223//! ```
2324//! #[derive(Debug)]
@@ -40,8 +41,8 @@
4041//! ```
4142//!
4243//! Pattern matching on [`Result`]s is clear and straightforward for simple
43-//! cases, but [`Result`] comes with some convenience methods that make working
44-//! with it more succinct.
44+//! simple cases, but [`Result`] comes with some convenience methods
45+//! that make working with it more succinct.
4546//!
4647//! ```
4748//! let good_result: Result<i32, i32> = Ok(10);
@@ -67,15 +68,16 @@
6768//!
6869//! # Results must be used
6970//!
70-//! A common problem with using return values to indicate errors is that it is
71-//! easy to ignore the return value, thus failing to handle the error.
72-//! [`Result`] is annotated with the `#[must_use]` attribute, which will cause
73-//! the compiler to issue a warning when a Result value is ignored. This makes
74-//! [`Result`] especially useful with functions that may encounter errors but
75-//! don't otherwise return a useful value.
71+//! A common problem with using return values to indicate errors is
72+//! that it is easy to ignore the return value, thus failing to handle
73+//! the error. [`Result`] is annotated with the `#[must_use]` attribute,
74+//! which will cause the compiler to issue a warning when a Result
75+//! value is ignored. This makes [`Result`] especially useful with
76+//! functions that may encounter errors but don't otherwise return a
77+//! useful value.
7678//!
77-//! Consider the [`write_all`] method defined for I/O types by the [`Write`]
78-//! trait:
79+//! Consider the [`write_all`] method defined for I/O types
80+//! by the [`Write`] trait:
7981//!
8082//! ```
8183//! use std::io;
@@ -85,11 +87,12 @@
8587//! }
8688//! ```
8789//!
88-//! *Note: The actual definition of [`Write`] uses [`io::Result`], which is just
89-//! a synonym for <code>[Result]<T, [io::Error]></code>.*
90+//! *Note: The actual definition of [`Write`] uses [`io::Result`], which
91+//! is just a synonym for <code>[Result]<T, [io::Error]></code>.*
9092//!
91-//! This method doesn't produce a value, but the write may fail. It's crucial to
92-//! handle the error case, and *not* write something like this:
93+//! This method doesn't produce a value, but the write may
94+//! fail. It's crucial to handle the error case, and *not* write
95+//! something like this:
9396//!
9497//! ```no_run
9598//! # #![allow(unused_must_use)] // \o/
@@ -102,12 +105,12 @@
102105//! file.write_all(b"important message");
103106//! ```
104107//!
105-//! If you *do* write that in Rust, the compiler will give you a warning (by
106-//! default, controlled by the `unused_must_use` lint).
108+//! If you *do* write that in Rust, the compiler will give you a
109+//! warning (by default, controlled by the `unused_must_use` lint).
107110//!
108-//! You might instead, if you don't want to handle the error, simply assert
109-//! success with [`expect`]. This will panic if the write fails, providing a
110-//! marginally useful message indicating why:
111+//! You might instead, if you don't want to handle the error, simply
112+//! assert success with [`expect`]. This will panic if the
113+//! write fails, providing a marginally useful message indicating why:
111114//!
112115//! ```no_run
113116//! use std::fs::File;
142145//!
143146//! # The question mark operator, `?`
144147//!
145-//! When writing code that calls many functions that return the [`Result`] type,
146-//! the error handling can be tedious. The question mark operator, [`?`], hides
147-//! some of the boilerplate of propagating errors up the call stack.
148+//! When writing code that calls many functions that return the
149+//! [`Result`] type, the error handling can be tedious. The question mark
150+//! operator, [`?`], hides some of the boilerplate of propagating errors
151+//! up the call stack.
148152//!
149153//! It replaces this:
150154//!
205209//!
206210//! *It's much nicer!*
207211//!
208-//! Ending the expression with [`?`] will result in the [`Ok`]'s unwrapped
209-//! value, unless the result is [`Err`], in which case [`Err`] is returned early
210-//! from the enclosing function.
212+//! Ending the expression with [`?`] will result in the [`Ok`]'s unwrapped value, unless the result
213+//! is [`Err`], in which case [`Err`] is returned early from the enclosing function.
211214//!
212-//! [`?`] can be used in functions that return [`Result`] because of the early
213-//! return of [`Err`] that it provides.
215+//! [`?`] can be used in functions that return [`Result`] because of the
216+//! early return of [`Err`] that it provides.
214217//!
215218//! [`expect`]: Result::expect
216219//! [`Write`]: ../../std/io/trait.Write.html "io::Write"
217-//! [`write_all`]: ../../std/io/trait.Write.html#method.write_all
218-//! "io::Write::write_all"
220+//! [`write_all`]: ../../std/io/trait.Write.html#method.write_all "io::Write::write_all"
219221//! [`io::Result`]: ../../std/io/type.Result.html "io::Result"
220222//! [`?`]: crate::ops::Try
221223//! [`Ok(T)`]: Ok
250252//!
251253//! ## Querying the variant
252254//!
253-//! The [`is_ok`] and [`is_err`] methods return [`true`] if the [`Result`] is
254-//! [`Ok`] or [`Err`], respectively.
255+//! In addition to working with pattern matching, [`Result`] provides a
256+//! wide variety of different methods.
255257//!
256258//! [`is_err`]: Result::is_err
257259//! [`is_ok`]: Result::is_ok
@@ -261,8 +263,8 @@
261263//! * [`as_ref`] converts from `&Result<T, E>` to `Result<&T, &E>`
262264//! * [`as_mut`] converts from `&mut Result<T, E>` to `Result<&mut T, &mut E>`
263265//! * [`as_deref`] converts from `&Result<T, E>` to `Result<&T::Target, &E>`
264-//! * [`as_deref_mut`] converts from `&mut Result<T, E>` to `Result<&mut
265-//! T::Target, &mut E>`
266+//! * [`as_deref_mut`] converts from `&mut Result<T, E>` to
267+//! `Result<&mut T::Target, &mut E>`
266268//!
267269//! [`as_deref`]: Result::as_deref
268270//! [`as_deref_mut`]: Result::as_deref_mut
@@ -271,18 +273,19 @@
271273//!
272274//! ## Extracting contained values
273275//!
274-//! These methods extract the contained value in a [`Result<T, E>`] when it is
275-//! the [`Ok`] variant. If the [`Result`] is [`Err`]:
276+//! These methods extract the contained value in a [`Result<T, E>`] when it
277+//! is the [`Ok`] variant. If the [`Result`] is [`Err`]:
276278//!
277279//! * [`expect`] panics with a provided custom message
278280//! * [`unwrap`] panics with a generic message
279281//! * [`unwrap_or`] returns the provided default value
280-//! * [`unwrap_or_default`] returns the default value of the type `T` (which
281-//! must implement the [`Default`] trait)
282-//! * [`unwrap_or_else`] returns the result of evaluating the provided function
282+//! * [`unwrap_or_default`] returns the default value of the type `T`
283+//! (which must implement the [`Default`] trait)
284+//! * [`unwrap_or_else`] returns the result of evaluating the provided
285+//! function
283286//!
284-//! The panicking methods [`expect`] and [`unwrap`] require `E` to implement the
285-//! [`Debug`] trait.
287+//! The panicking methods [`expect`] and [`unwrap`] require `E` to
288+//! implement the [`Debug`] trait.
286289//!
287290//! [`Debug`]: crate::fmt::Debug
288291//! [`expect`]: Result::expect
@@ -291,9 +294,9 @@
291294//! [`unwrap_or_default`]: Result::unwrap_or_default
292295//! [`unwrap_or_else`]: Result::unwrap_or_else
293296//!
294-//! These methods extract the contained value in a [`Result<T, E>`] when it is
295-//! the [`Err`] variant. They require `T` to implement the [`Debug`] trait. If
296-//! the [`Result`] is [`Ok`]:
297+//! These methods extract the contained value in a [`Result<T, E>`] when it
298+//! is the [`Err`] variant. They require `T` to implement the [`Debug`]
299+//! trait. If the [`Result`] is [`Ok`]:
297300//!
298301//! * [`expect_err`] panics with a provided custom message
299302//! * [`unwrap_err`] panics with a generic message
@@ -308,10 +311,10 @@
308311//!
309312//! * [`err`][Result::err] transforms [`Result<T, E>`] into [`Option<E>`],
310313//! mapping [`Err(e)`] to [`Some(e)`] and [`Ok(v)`] to [`None`]
311-//! * [`ok`][Result::ok] transforms [`Result<T, E>`] into [`Option<T>`], mapping
312-//! [`Ok(v)`] to [`Some(v)`] and [`Err(e)`] to [`None`]
313-//! * [`transpose`] transposes a [`Result`] of an [`Option`] into an [`Option`]
314-//! of a [`Result`]
314+//! * [`ok`][Result::ok] transforms [`Result<T, E>`] into [`Option<T>`],
315+//! mapping [`Ok(v)`] to [`Some(v)`] and [`Err(e)`] to [`None`]
316+//! * [`transpose`] transposes a [`Result`] of an [`Option`] into an
317+//! [`Option`] of a [`Result`]
315318//!
316319// Do NOT add link reference definitions for `err` or `ok`, because they
317320// will generate numerous incorrect URLs for `Err` and `Ok` elsewhere, due