From d5cb5eb08bc75cd9cd297b15cfac8bded9edc053 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Kornel=20Lesi=C5=84ski?= Date: Sat, 15 Aug 2020 12:34:15 +0100 Subject: [PATCH] Doc: String isn't a collection --- library/core/src/iter/traits/iterator.rs | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) 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`][`Result`] can be thought of as single - /// [`Result`]`, 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`][`Result`] items can be collected + /// into `Result, 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 -- 2.44.0