Reed Copsey, Jr. has been writing a great series of articles on parallelism with the .NET Framework 4…

I suspect that they did this, mainly because they wanted this to exist on the IObservable side, and wanted to keep feature parity on the IEnumerable side, as well. Most of the arguments I make above for asynchronous operations apply to IObservable – in which case, it makes sense.

I actually, though, personally do not like the EnumerableEx.Do(…) implementation in the Rx framework. It leaves a “real bad taste” when I’ve used it, since it has some odd, unexpected behavior (ie: it doesn’t actually perform the action until you enumerate through it, which makes sense, but is odd). I particularly don’t like that .Do() returns an IEnumerable, so it can be used in the middle of expressions, even though it’s a statement intended to cause side effects. Personally, it seems no different than a slightly restricted form of Select() [since you can do the exact same thing with a Select(..) call].

Regarding the philosophical arguments, I must point out that the Rx team (who are very functionally minded) did choose to include Do and Run (which are essentially ForEach) for IEnumerables as well as IObservables.

At some point, pragmatism must be considered. Functional code must eventually produce side effects, and no one is really interested in forcing all LINQ side effects to be monads…