Eric Lippert on the decision to omit Enumerable.ForEach

Found another interesting post on Eric Lippert’s blog, this one explain the rationales behind why there’s no built-in Enumerable.ForEach extension method, one which myself and no doubt many others had decided to implement ourselves.

As he explains, there are two main philosophical reasons why he’s against such an extension method:

"The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects."

"The second reason is that doing so adds zero new representational power to the language. Doing this lets you rewrite this perfectly clear code:

foreach(Foo foo in foos){ statement involving foo; }

into this code:

foos.ForEach((Foo foo)=>{ statement involving foo; });

which uses almost exactly the same characters in slightly different order. And yet the second version is harder to understand, harder to debug, and introduces closure semantics, thereby potentially changing object lifetimes in subtle ways."

Well, that clears a few things up, hearing from one of the guys on the C# compiler team.


Eric Lippert – foreach vs ForEach

Yan Cui

I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.

You can contact me via Email, Twitter and LinkedIn.

Hire me.