Eric Lippert on the decision to omit Enumerable.ForEach

Presently sponsored by Serverless Guru: Your guide to cloud excellence, helping you every step of your serverless journey, including team training, pattern development, mass service migrations, architecting, and developing new solutions. Speak to a Guru today.

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

Leave a Comment

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