Func<T> is just the type signature they use for lambdas. The syntax allows fully inline functions now:

() => { DoSomething(); }

No return value needed (compiles down to an Action<T> I think)

> No return value needed (compiles down to an Action<T> I think)

Which is an other crufty thing in C#: because Void/() is not a type (inherited from Java), it needs to have both `Func<Tn..., T>` and `Action<Tn...>` in order to handle functions-with-a-return-value and functions-without-a-return-value.

This is true, but its mostly transparent unless you're doing something particularly ugly.

Like trying to take one of these as parameter or return it?

This is a statically typed language mind you. If you're passing something around as values, you're gonna need to declare what its type is (of course there's type inference, but that just turns it into a totally different language)

> If you're passing something around as values, you're gonna need to declare what its type is

I fail to see the relation this has with my issue.

You should need to know whether you require the lambda you're accepting to return some value or not, and its type.

You completely missed the point I was making. Try reading these comments again.

Can't recursively call a lambda function, no thanks.

There are two ways of recursively calling lambda functions, neither perfect, but both usable.

  Func<int,int> fib = null;
  fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;

Or write yourself a Y fixed-point combinator, described in http://blogs.msdn.com/b/wesdyer/archive/2007/02/02/anonymous...

  delegate Func<A,R> Recursive<A,R>(Recursive<A,R> r);
  static Func<A, R> Y<A, R>(Func<Func<A, R>, Func<A, R>> f) {
    Recursive<A, R> rec = r => a => f(r(r))(a);
    return rec(rec);
  }

used like this:

  Func<int,int> fib = Y<int,int>(f => n => n > 1 ? f(n - 1) + f(n - 2) : n);

(I'm not advocating writing a fib function this way, but it's a useful example!)

I also feel like "Funcs" are a work around. What I like the most about C# is the fact that it keeps evolving and incorporating new paradigms (closures, lambdas, LINQ, etc)

Try F# then, tuples, records, pattern matching, etc. It's essentially OCaml.net

Have used F# quite a bit. It's nice, the nicest ML I've used, but it has some cruft as well. It feels like 2 languages, really, the nice functional ML language, and then the C#-with-F#-syntax object oriented side. I wish they wouldn't have bothered with the latter.

Actually the OO side is quite similar to OO in OCaml, so I miss your C# remark there.

For a language to be first class in .NET it needs to be able to do OO with the same semantics that the CLR has, otherwise you will have leaky abstractions all over the place.

Yeah, C# tuples are a pretty glaring hack in an otherwise great, evolving language.

Like other C# features and behaviors, I expect that, down the line, the language will pick up syntactic sugar to make the creation and usage of those tuples more straightforward (see delegates -> anonymous functions -> lambdas).

Yeah and F# is the breeding ground for C# features

Func<T> are part of expression trees.

They are intended to manipulate the abstract syntax tree of lambda expressions. A bit like macros.

You should only need to know about them if doing AST manipulations.