views:

555

answers:

2

So when I write something like this

Action action = new Action(()=>_myMessage = "hello");

Refactor Pro! Highlights this as a redundant delegate creation and allows me to to shorten it to

Action action = () => _myMessage="hello";

And this usually works great. Usually, but not always. For example, Rhino Mocks has an extension method named Do:

IMethodOptions<T> Do(Delegate action);

Here, passing in the first version works, but the second doesn't. What exactly is going on under the covers here?

+5  A: 

Have you verified the second line actually compiles? It should not compile because C# does not support assigning a lambda expression to an implicitly typed variable (CS0815). This line will work in VB.Net though because it supports anonymous delegate creation (starting in VB 9.0).

The Rhino Mocks version does not compile for the same reason the second line should not compile. C# will not automatically infer a type for a lambda expression. Lambda expressions must be used in a context where it is possible to determine the delegate type they are intended to fulfill. The first line works great because the intended type is clear: Action. The Rhino Mocks version does not work because Delegate is more akin to an abstract delegate type. It must be a concrete delegate type such as Action or Func.

For a detailed discussion on this topic, you should read Eric Lippert's blog entries on the subject: http://blogs.msdn.com/ericlippert/archive/2007/01/11/lambda-expressions-vs-anonymous-methods-part-two.aspx

JaredPar
+4  A: 

The first version is effectively doing:

Action tmp = () => _myMessage = "hello";
var action = new Action(tmp);

The problem you're running into is that the compiler has to know what kind of delegate (or expression tree) the lambda expression should be converted into. That's why this:

var action = () => _myMessage="hello";

actually doesn't compile - it could be any delegate type with no parameters and either no return value or the same return type as _myMessage (which is presumably string). For instance, all of these are valid:

Action action = () => _myMessage="hello";
Func<string> action = () => _myMessage="hello";
MethodInvoker action = () => _myMessage="hello";
Expression<Action> = () => _myMessage="hello";
// etc

How could the C# compiler work out what type action was meant to be, if it were declared with var?

The simplest way to get round this when calling a method (for your Rhino Mocks example) is to cast:

methodOptions.Do((Action) () => _myMessage = "hello");
Jon Skeet
VB.Net is able to get around this by generating delegate types on the fly based on the usage. Because VB already differentiates between void and non-void returning functions (sub and function) it makes the differentiation easier
JaredPar
"How could the C# compiler work out what type action was meant to be, if it were declared with var?" Simple: function types should be first class structural types, not this named delegate stuff. And quoted code should be noted as such. But I guess that won't change now :).
MichaelGG