From: Kornel Lesiński <kornel@geekhood.net>
Date: Sat, 15 Aug 2020 11:34:15 +0000 (+0100)
Subject: Doc: String isn't a collection
X-Git-Url: https://git.lizzy.rs/?a=commitdiff_plain;h=d5cb5eb08bc75cd9cd297b15cfac8bded9edc053;p=rust.git

Doc: String isn't a collection
---

diff --git a/library/core/src/iter/traits/iterator.rs b/library/core/src/iter/traits/iterator.rs
index 3ea3eeed6b0..f89b616c4e2 100644
--- a/library/core/src/iter/traits/iterator.rs
+++ b/library/core/src/iter/traits/iterator.rs
@@ -1543,11 +1543,10 @@ fn by_ref(&mut self) -> &mut Self
     /// collection into another. You take a collection, call [`iter`] on it,
     /// do a bunch of transformations, and then `collect()` at the end.
     ///
-    /// One of the keys to `collect()`'s power is that many things you might
-    /// not think of as 'collections' actually are. For example, a [`String`]
-    /// is a collection of [`char`]s. And a collection of
-    /// [`Result<T, E>`][`Result`] can be thought of as single
-    /// [`Result`]`<Collection<T>, E>`. See the examples below for more.
+    /// `collect()` can also create instances of types that are not typical
+    /// collections. For example, a [`String`] can be built from [`char`]s,
+    /// and an iterator of [`Result<T, E>`][`Result`] items can be collected
+    /// into `Result<Collection<T>, E>`. See the examples below for more.
     ///
     /// Because `collect()` is so general, it can cause problems with type
     /// inference. As such, `collect()` is one of the few times you'll see