trjhtr

I found myself wanting to use Linq to map void methods to an IEnumerable to modify all items. The existing Linq methods require a return variable when mapping, since they are based on Func.

So I decided to try my hand at creating some extension methods myself. This is the first time I've done anything like this, so if there are any pitfalls I'm missing, please do tell.

I created two extensions, one which applies a foreach loop to all elements, calling an Action<T> for each. The second one is basically the Zip extension, which allows for two IEnumerables to be iterated together and again maps a Action<T1,T2> to both of them.

public static void ForEachAction<T>(this IEnumerable<T> sequence, Action<T> action) 
 foreach(T value in sequence) 
 action(value);
 


public static void ForEachActionZip<Tbase, Tsecond>(this IEnumerable<Tbase> sequence, IEnumerable<Tsecond> second, Action<Tbase, Tsecond> action) 
 sequence.Zip(second, (first, other) => new first, other ).ForEachAction(x => action(x.first, x.other));

You can then use this like so:

someList.ForEachAction(x => x.Update());

or

someList.ForEachActionZip(secondList, (a, b) => a.Update(b));

This is generally considered to be a bad idea. IEnumerable has deferred execution, which means that in your example, someList can be forced to enumerate any desired number of times.

As a consequence, it depends on the implementation behind the IEnumerable whether any changes applied by action will still be visible after your methods have run. There are two possibilities:

1. 
   someList is a materialized list (for example, List<SomeObject>). After running ForEachAction, a new enumeration of someList will produce the same, modified, objects.


2. 
   someList is an enumerable that produces new objects on each execution. After running ForEachAction, a new enumeration of someList will produce new objects. The changed objects are out of scope and will soon be garbage collected.

An example of the second option is an IQueryable against a SQL backend. When it is executed it will emit a SQL query that returns new objects from the database (caching as applied by many ORMs aside).

In that case it totally depends on what happens in action whether any effect of it is persistent. If action only modifies objects in someList its effect will be lost. If it uses objects in someList to change some external state (e.g. increment some sum value) its effect will persist.

As a conclusion, I wouldn't do this. If you want to apply void methods to any IEnumerable, first materialize it to a list and then apply existing methods. Instead of...

someList.ForEachAction(x => x.Update());

...you'd have...

var concreteList = someList.ToList();
concreteList.ForEach(x => x.Update());

Now continue working with concreteList so you'll be sure that the effect of x.Update() will remain visible in your code.

If you want them to act a bit more like the Microsoft-supplied LINQ extension methods, you may want to consider some parameter checks (for example):

public static void ForEachAction<T>(this IEnumerable<T> sequence, Action<T> action) 
 if (sequence== null) 
 throw new ArgumentNullException(nameof(sequence));
 

 if (action== null) 
 throw new ArgumentNullException(nameof(action));
 

 sequence.ForEachActionInternal(action);


private static void ForEachActionInternal<T>(this IEnumerable<T> sequence, Action<T> action) 
 foreach(T value in sequence) 
 action(value);
 

I've split it into two methods in case you decide to have your methods return a sequence of some sort lazily.