C#'s answer for all of its missing features seems to be a generic class. Don't have tuples? We'll give you Tuple<T>. Don't have inline functions? We'll give you Func<T>. It feels very tacked on (especially Func).
C#'s answer for all of its missing features seems to be a generic class. Don't have tuples? We'll give you Tuple<T>. Don't have inline functions? We'll give you Func<T>. It feels very tacked on (especially Func).
() => { DoSomething(); }
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.
I fail to see the relation this has with my issue.
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!)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.
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.