tags:

views:

74

answers:

3

In the following delegate example, how does the compiler infer what type the variable alpha is?

delegate double Doubler(double x);

public class Test
{
    Doubler dbl = (alpha) => //How does it determine what type is alpha?
    {
        return alpha * 2
    };

    Console.WriteLine(dbl(10)); //Is it when the method is called?  int here;

    Console.WriteLine(dbl(5.5)); //double here???
}

I found this statement on a website, I guess based on the responses, is it incorrect?

"In our example, we specified the type of the argument. If you want, you can let the compiler figure out the type of argument. In this case, pass only the name of the argument and not its type. Here is an example:"

+6  A: 

You declare it in your delegate.

delegate double Doubler(double x);

x is your alpha.

You could easily replace your code with:

Doubler dbl = delegate (double x)
{
   return x*2;
};

Also you could simplify your lambda expression:

Doubler dbl = alpha => alpha*2;
Vadim
Hmmm, didn't think of that, so is it true that the compiler actually does not infer the type?
Xaisoft
No, not in this case. However it can infer the type if you use a generic constraint.
atsjoo
Can you provide an example of what you mean by generic constraint.
Xaisoft
Thanks for the lambda expression help. I just started working with them.
Xaisoft
This isn't part of the actual question, but what that lambda expression actually doing if you had to explain in english to a newbie?
Xaisoft
The reason I ask is why can't I do Doubler dbl = alpha * 2; or Doubler dbl => alpha * 2 or can I do this? Sorry I am new.
Xaisoft
Please read the documentation first: http://msdn.microsoft.com/en-us/library/bb397687.aspx - see if you have any questions remaining after that.
Pavel Minaev
@Pavel, Thanks for the link.
Xaisoft
+1  A: 

You specified that the input type is double when you defined the Doubler delegate. For both examples the input type is double.

atsjoo
+5  A: 

This language feature looks simple but in fact is really quite complicated. It would take far too much space to describe here exactly what all the consequences of this feature are. If you are really interested in how the compiler works out the type of the formal parameter to the lambda, you should read my five-part series of articles discussing how we do this, and what the consequences are to the compiler design.

Here's my archive of all my articles where I discuss the implications of lambda expressions:

http://blogs.msdn.com/ericlippert/archive/tags/Lambda+Expressions/default.aspx

You should read the series entitled "Lambda Expressions vs. Anonymous Methods".

If you're interested in how the compiler performs other type inferences, here's my archive of articles on that:

http://blogs.msdn.com/ericlippert/archive/tags/Type+Inference/default.aspx

If you're the sort of person who prefers watching video to reading text, here's a video I made in 2006 explaining some of the type inference scenarios:

http://blogs.msdn.com/ericlippert/archive/2006/11/17/a-face-made-for-email-part-three.aspx

Eric Lippert
Great! Thanks for the resources. I read your blog all the time by the way even if I don't understand it :)
Xaisoft