@@ -112,7 +112,7 @@ mod prim_bool { }
112112///
113113/// # `!` and generics
114114///
115- /// ## Infalliable errors
115+ /// ## Infallible errors
116116///
117117/// The main place you'll see `!` used explicitly is in generic code. Consider the [`FromStr`]
118118/// trait:
@@ -144,7 +144,7 @@ mod prim_bool { }
144144///
145145/// ## Infinite loops
146146///
147- /// While [`Result<T, !>`] is very useful for removing errors, `!` can also be used to removed
147+ /// While [`Result<T, !>`] is very useful for removing errors, `!` can also be used to remove
148148/// successes as well. If we think of [`Result<T, !>`] as "if this function returns, it has not
149149/// errored," we get a very intuitive idea of [`Result<!, E>`] as well: if the function returns, it
150150/// *has* errored.
@@ -175,21 +175,22 @@ mod prim_bool { }
175175/// ```
176176///
177177/// Now, when the server disconnects, we exit the loop with an error instead of panicking. While it
178- /// might be intuitive to simply return the error, we might want to wrap it in a [`Result<!, E>`]
178+ /// might be intuitive to simply return the error, we might want to wrap it in a [`Result<!, E>`]
179179/// instead:
180180///
181181/// ```ignore (hypothetical-example)
182182/// fn server_loop() -> Result<!, ConnectionError> {
183- /// Ok( loop {
183+ /// loop {
184184/// let (client, request) = get_request()?;
185185/// let response = request.process();
186186/// response.send(client);
187- /// })
187+ /// }
188188/// }
189189/// ```
190190///
191191/// Now, we can use `?` instead of `match`, and the return type makes a lot more sense: if the loop
192- /// ever stops, it means that an error occurred.
192+ /// ever stops, it means that an error occurred. We don't even have to wrap the loop in an `Ok`
193+ /// because `!` coerces to `Result<!, ConnectionError>` automatically.
193194///
194195/// [`String::from_str`]: str/trait.FromStr.html#tymethod.from_str
195196/// [`Result<String, !>`]: result/enum.Result.html
0 commit comments