C# with lambda syntax and extension methods (in lieu of compositional operators) gets us so far, but the syntax and compiler could use a bit of polish. I'll show some exact examples later, but meanwhile this picture sums up my feelings at the moment:

I'm really confused with all this lambda stuff lately... it's like a complete new language andnone of the books seem to explain it in normal people's language... feels like you're supposed to bea rocket scientist to understand some of the books (and I never had this problem before :p)

Anyway, I'm guessing you don't like the fact that the editor is telling you it's wrong? :p

Sorry I didn't make it clear; it's a C# spec issue in general -- such things are simply not allowed (hopeful note: yet!).

Taking a more-functional approach to C# (lambdas being the big syntactic benefit) can be very confusing at first. However, in some scenarios, it is much more powerful, and all C# developers would do good to learn it. You bring up an interesting point that the materials out there don't seem to be clear. I'd like to see more people adopt functional programming, and I'd like to learn what is perceived as being difficult about it.

The majority of developers I've approached seem against it. I think I've only seen 2 or 3 people's eyes light up when they get what they can do with it. I'd like to change that (although people much smarter than me have tried before...).

I agree that some of the warnings are annoying, but inferencing the type of the local variable "add" is tricky. If I recall correctly, O'Caml can only infer the type of "add" because the "+" operator only adds integers. To add floating point numbers, you need to use a different operator. C# allows the "+" operator for many different types, so it can't do what O'Caml does.

One possible solution is to do more global inference (i.e. use information about how the variable 'add' is used to refine the type further), but this has some issues. It makes the type inference much more complicated and harder to predict for the programmer. It also wont work all the time.

What Haskell does (roughly) is define an "Num" interface that has addition and subtraction methods. A Haskell-like type inferencer would yield something like "func<T>(T, T) -> T [where T : Num]". C# would probably need a separate "Plusable" interface because there are non-numeric operations that use the "+" operator (for example, string concatenation). A potential problem here is that it's now easy to accidentally use the generic version even when you only really need integer addition; the code will end up performing unnecessary virtual method calls and integer value boxing. Then again, maybe the compiler should trust you and leave the performance-related warnings to tools like FxCop. (Also, a good cross-procedure optimizer can also help.)

Kannan, you're right that C# right now can't infer from operators because it has no way of putting a generic constraint on such a function. It's been discussed before: adding some kind of operator constraint for generics. For instance here:

I know I've seen other conversations on that but can't find them right now. But, I'll admit, this is the least important issue; I threw it in for fun.

As far as performance on those kinds of things, that's what I'd expect the platform to sort out for me. If someone writes straightforward code and it has some kind of a hidden perf hit, so much worse for the platform.

That second line should work. A lambda expression with explicitly typed arguments should have it's type inferred.I filed a bug report here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=294156