-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add for_each function to Iterator trait #14911
Conversation
/// a.iter().for_each(|x| println!("{}", x)); | ||
/// ``` | ||
#[inline] | ||
fn for_each(mut self, f: |A|) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.