Eric Lippert on the decision to omit Enumerable.ForEach

Yan Cui

I help clients go faster for less using serverless technologies.

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.

References:

Eric Lippert – foreach vs ForEach


Whenever you’re ready, here are 3 ways I can help you:

  1. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game.
  2. Consulting: If you want to improve feature velocity, reduce costs, and make your systems more scalable, secure, and resilient, then let’s work together and make it happen.
  3. Join my FREE Community on Skool, where you can ask for help, share your success stories and hang out with me and other like-minded people without all the negativity from social media.

 

Leave a Comment

Your email address will not be published. Required fields are marked *