Using C# as an example, extensions on IEnumerable to allow code like collection.Each(i => i.DoStuff) rather than a foreach loop are generally frowned upon, mainly because they don't follow LINQ conventions of being functional, in that the functions they take are statements rather than expressions, written to have side-effects.

Does the same thing apply to an extension to allow code like...

10.times(() => ThingIWantToDo10Times())

On one hand it's still clearly not functional, but on the other, it's not an extension on IEnumerable.

Would an extension like this be frowned upon for the same reasons?


The first thing to note is that your second code example is verbose and thus hides one of the key benefits to your extension method. It can be expressed as:


(though make that Times, please. C# methods are PascalCase, not camelCase.)

The terseness of such an expression is a big plus point. But, you are right, many folk do not like it as it's using a functional pattern to create side-effects. It's worth reading this post by Eric Lippert, as it goes into a lot of detail on why that can be seen as wrong.

If though, after reading that, you still prefer the idea of using an extension method, then do so. It's all just opinion after all...

  • 3
    Tenseness of such an expression is a slight negative. Give me a plain old loop any day. Easier to read, way easier to maintain and debug. The obsessive focus on brevity is in part why functional languages remain on the fringes. – Telastyn Jun 27 '18 at 16:44
  • 2
    @Telastyn: The real problem here is the side-effects in a functional context, not brevity necessarily. Also, what is a fluent interface actually doing under the covers? Hard to tell without looking at the underlying source code. – Robert Harvey Jun 27 '18 at 17:12
  • @Telastyn, sure some folk dislike declarative code and want to see what's really going on. Assembler is a good choice for those folk. – David Arno Jun 28 '18 at 7:31
  • I've read that Eric Lippert article a number of times, and totally agree with it, but it's concentrating on sequence operators. This extension isn't on sequence, and has clear side-effecting semantics, which is why I wonder if the concerns about the non-functional-ness of it still apply. – GoatInTheMachine Jun 28 '18 at 10:32
  • Higher order functions can be useful without having to go 100% pure functional programming. OP has provided a nice example, especially considering that the host language is C# which is very non-pure-functional. By the same reasoning we would not be allowed to use callbacks with side effects! Instead, there's a much simpler argument against this extension method: it's unidiomatic in C# (but compare e.g. Smalltalk or Ruby where such methods are be idiomatic). – amon Jun 28 '18 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.