Glenn Block

I just wrote this in a Main method:

           List<string> items = new List<string>();

           items.Add("Item 1");

           items.Add("Item 2");

           items.Add("Item 3");

           items.ForEach(s => Console.WriteLine(s));

Is this not what you want?  I'm running VS 2008 on .NET 3.5.

No Neil, List<T> is probably too much what he wants.

I also was wondering why the ForEach method was put inside List<T> and not IEnumerable<T> ?

Ahh, of course.  He only has the IEnumerable interface and my example was getting ForEach from List<T>.

Gosh, I amaze myself with my own stupidity sometimes.

here is a similar work I have done:  www.sidarok.com/.../building-a-configuration-binder-for-mef-with-poco-support.html

There's also no equivalent on System.Linq.Enumerable, which has irked me on several occasions.

Ah! And don't forget ForEach's cousin, with an index:

public static void Each<T>(this IEnumerable<T> items, Action<T, int> action)

{

int i = 0;

foreach (var item in items)

{

action(item, i++);

}

}

Beautiful. I'm a fan of anything that makes C# act more like Ruby.

I've often wondered why a ForEach wasn't added for IEnumerable<T>.  It's very handy on List<T>...

Took me less than 5 seconds to google an existing solution :)

davesquared.blogspot.com/.../ienumerable-and-foreach.html

I've been (over?)thinking about this for a while now and have currently settled on using ToList().Foreach() instead. What bothers me about the implementation you show is that it breaks the conventions of Linq extension methods in that it's not chainable, and it's not lazy. So, while it's possible to do .Where().Select().Foreach(), its not possible to do .Where().Foreach().Select().

This is obviously by design and it works as you needed it to but it feels a bit ambiguous to me. I tried to think of another name for it, something that would communicate the distinction, but nothing felt right.

Using .ToList().Foreach() is more explicit in what the intention is, but it has an extra method in the chain, and it's enumerating the collection twice, so I'm not much happier with it either.

Am I just overworking this idea?

Ugh, just realised how stupid my comment was. It's exactly what you were talking about. Sleep.

In summary, enumerating an enumerable seems like the perfect thing for System.Linq.Enumerable to do. And yet it doesn't.

Inconsistencies. ugh.

I think the reason ForEach wasn't added to IEnumerable<T> (not via extension methods, but to the interface itself) was that doing so would require reimplementation of this 'algorithm' by anyone who implements IEnumerable<T>.  That would be painful at best and error-prone at worst.

I like this as a better implementation:

public IEnumerable<TSource> ForEach(this IEnumerable<TSource> collection, Action<TSource> action) {

   foreach(var item in collection) {

       action(item);

       yield return item;

   }

}

@Bill

I can see the value in, though I would have adifferent name then. foreach in fx by itself only yields if I add the yield statement.

Glenn

@Kelly

Sure, but to keep with how LINQ extensions were handled, it would have been added via an extension method to the interface ;)

I suspect the reason that this didn't exist before is that you can't use it from VB. VB only support lambda expressions, while the foreach method requires a lambda *statement*.

Any reason you didn't check for nulls?

My assumption as to why the Enumerable class doesn't provide a ForEach extension method is because there are a number of valid implementations, using either deferred or immediate execution. I wrote more about this a couple of months back: gregbeech.com/.../why-doesn-t-system-linq-enumerable-have-a-foreach-extension-method.aspx

Both Yoshi Carroll in the comment above, and Greg Beech in his linked post comment that Linq uses deferred execution and chaining.  That's simply not true.  Some parts of Linq follow this, but not all.  Just one example is Average, which is neither chainable nor does deferred execution.  I can't begin to guess why ForEach was left out, but it seems obvious that's not why.

I left a full response on my blog post (where wekempf also posted a comment). The essence is that not all LINQ operations are chainable or deferred, but all operations that are chainable are also deferred, and vice versa. As it isn't clear whether ForEach should be chainable, it isn't clear whether it should be deferred.

I posted on your blog as well, but the gist of my post is that to those who have used other functional languages, it is clear that ForEach should not be chainable.

Últimamente ya no escribo nada, estoy totalmente inmerso en el mundo LINQ con el C# 3.0 y LINQ de Octavio

Últimamente ya no escribo nada, estoy totalmente inmerso en el mundo LINQ con el C# 3.0 y LINQ de Octavio

Recientemente, Valeriano Tórtola publicó un excelente post en el que mostraba la utilización de un método