Conversation
|
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
I think this is what #48945 originally proposed. |
| #[inline] | ||
| #[unstable(feature = "iter_exhaust", issue = "44546")] | ||
| fn exhaust(self) where Self: Sized { | ||
| for _ in self {} |
There was a problem hiding this comment.
This should use for_each to get internal iteration, rather than (implicit) next() calls.
There was a problem hiding this comment.
It doesn't matter so much now the PR's closed, but out of curiosity, what difference in behaviour would using for_each have?
There was a problem hiding this comment.
The difference is that some iterators can apply a fold much more efficiently than they can next one item at a time. For instance, Chain::fold can fold its first part as a whole, then its second part as a whole, but Chain::next has to check whether it's on the first or second part every time. This is demonstrated in the benchmarks added to the for_each PR, #42782, in commit 4a8ddac.
There was a problem hiding this comment.
Ah, of course, that makes a lot of sense. Thanks for explaining!
This adds an
Iterator::exhaustmethod for evaluating the side effects of an iterator conveniently. There are already ways to do this simply, but a little uglily (e.g.iter.for_each(|_| ())oriter.collect::<()>()) and it was proposed in #44546 that it'd be nicer to have a dedicated (and discoverable) method to do this.Closes #44546.
r? @dtolnay