Add for_each function to Iterator trait#14911
Add for_each function to Iterator trait#14911aochagavia wants to merge 1 commit intorust-lang:masterfrom aochagavia:foreach
Conversation
src/libcore/iter.rs
Outdated
There was a problem hiding this comment.
This should take &mut self like the other consumers (e.g. advance and count), and should be moved down towards the bottom of the trait with them.
|
My second comment brings me onto something else... I don't think this method is particularly useful; it's just a constrained version of the I'm personally quite happy writing |
|
I agree with you that closures with side-effects are ugly. I think, however, that it is tiresome to write 3 lines of code to do something so simple as |
|
I was looking for something like this yesterday, nice! ref #14666. EDIT: thestinger has a valid point though. |
|
I was pointed to an article of Eric Lippert on why they didn't implement a There is an interesting discussion at the end of the article, where arguments in favor of I still think it would be nice to have this, because it is very practical. |
|
I don't understand the reasoning behind adding a method like this. It's strictly uglier than using a.iter().for_each(|x| println!("{}", x));
for x in a.iter() { println!("{}", x) } |
|
Agreed with thestinger, this is pointless. |
|
After the example of @thestinger it is clear that this is not so convenient as it looked like to me before. If nobody has new arguments, I think this PR should be closed. |
This works like a `for` loop in functional style, applying a closure to every item in the `Iterator`. It doesn't allow `break`/`continue` like a `for` loop, nor any other control flow outside the closure, but it may be a more legible style for tying up the end of a long iterator chain. This was tried before in rust-lang#14911, but nobody made the case for using it with longer iterators. There was also `Iterator::advance` at that time which was more capable than `for_each`, but that no longer exists. The `itertools` crate has `Itertools::foreach` with the same behavior, but thankfully the names won't collide. The `rayon` crate also has a `ParallelIterator::for_each` where simple `for` loops aren't possible. > I really wish we had `for_each` on seq iterators. Having to use a > dummy operation is annoying. - [@nikomatsakis][1] [1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
Add `Iterator::for_each` This works like a `for` loop in functional style, applying a closure to every item in the `Iterator`. It doesn't allow `break`/`continue` like a `for` loop, nor any other control flow outside the closure, but it may be a more legible style for tying up the end of a long iterator chain. This was tried before in #14911, but nobody made the case for using it with longer iterators. There was also `Iterator::advance` at that time which was more capable than `for_each`, but that no longer exists. The `itertools` crate has `Itertools::foreach` with the same behavior, but thankfully the names won't collide. The `rayon` crate also has a `ParallelIterator::for_each` where simple `for` loops aren't possible. > I really wish we had `for_each` on seq iterators. Having to use a > dummy operation is annoying. - [@nikomatsakis][1] [1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
Allow setting cfgs Fixes rust-lang/rust-analyzer#14365
No description provided.