confusion about the lambda expression and delegate? - c#

Delegate is clear to understand
delegate int del(int i);
but why can we use
del myDelegate = x => x * x;
Questions here:
How can I assure x is int type in the lambda expresison?
How can I know lambda expression return a int?

C# compiler is smart enough to implicitly figure out the type of x on the left side of => from the context. Since it knows that you are assigning the lambda to a variable of type del, the compiler knows that x is an int.
As far as the return type goes, the compiler knows that x is an int, therefore the type of the x * x expression must also be int. That's how the compiler knows the return type of the lambda.
Note that the same code would not have compiled without the exact type of myDelegate specified:
// This does not compile!
var myDelegate = x => x*x;

Because for you to have x, you had to give it a type. It will detect this type rather than making you tell it over and over what type it is.

Right now you're letting the compiler determine what the lamdba expression is doing. You can sublclass using Action and Func
Actions return type is void while Func's return type is whatever you specify as the last type parameter. You can specify additional inputs in both
Func<in, in2, in3, output>
For returning an int
var f = new Func<int, int>(x => x*x);

Related

What's the datatype of lambda-expressions?

i have a small question i just can't figure out myself, what is the datatype of a lambda-expression like this:
x => x>0
I hope you can help me.
It's just a Func<T, bool> where T is type of x.
In general, Func<T, TResult> is the one of predefined delegate types for a method that accepts one argument of type T (x in your case) and returns some value of the type TResult (bool in your case)
More info here
Lambda expressions don't have a definite type. The types that a lambda expression can be implicitly converted to is either delegate or Expression type.
You can find more information here
"Note that lambda expressions in themselves do not have a type because the common type system has no intrinsic concept of "lambda expression." However, it is sometimes convenient to speak informally of the "type" of a lambda expression. In these cases the type refers to the delegate type or Expression type to which the lambda expression is converted."
For your specific example some of the types to which the lambda can be assigned are:
Predicate<int> predicate = x => x > 0;
Func<int, bool> func = x => x > 0;
Expression<Func<int, bool>> expression = x => x > 0;

Lambda Expression definition (pedant )?

By just briefing a book (leading one) , one thing caught my eyes - the lambda expression definition :
A lambda expression is an unnamed method written in place of a
delegate instance.
in place of delegate instance ???
A delegate instance is an object that refers-to/encapsulate target method/s :
In the following sample The right side(where the lambda expression would be) is not a delegate instance. it is a method.
TransformerDelegate t = SquareMethod;
So the definition should have been corrected-to/mention :
lambda expression are unnamed method written in place of a method(!)
being referenced by delegate variable.
TransformerDelegate sqr = x => x * x;
^
|
---------------+
|
this is the location for method/anonymous methods.
do you see what I mean ? Am I right?
p.s. I did understand the msdn's one : ( but want to see if the book had made a mistake)
A lambda expression is an anonymous function that can contain
expressions and statements, and can be used to create delegates or
expression tree types.
The value of a lambda expression is a delegate instance.
So the book is probably referring to code like:
MySquareDelegate f1 = x => x * x;
MySquareDelegate f2 = new MySquareDelegate(MySquareMethod);
MySquareDelegate f3 = MySquareMethod; // just shorthand for the previous line
It is tricky stuff to explain in 1 sentence, your own version
lambda expression are unnamed method written in place of a method(!) being referenced by delegate variable.
is talking about "a method instead of a method", the original about "a method instead of a delegate instance" where the method is implicitly converted to a delegate instance. Both seem incomplete at least.
A definition of a lambda should also include that it is an inline method.
Other answers miss the fact that lambda expressions do not necessarily represent methods. Sometimes, they represent expression trees.
The compiler implicitly converts lambda expressions to one type of object or the other, depending on context.
To specify a method, you need to specify parameters and a body. In a lambda expression, these are separated by =>. Examples:
() => 4; //empty parameter list
x => x.ToString(); //one parameter
(a, b) => a.Equals(b); //two parameters
// ^^^^^^ ^^^^^^^^^^^^
// | |
// parameter list body
These lambda expressions can be converted to Func<int>, Func<object, string>, and Func<object, object, bool> respectively. The could also be converted to Expression<Func<int>>, Expression<Func<object, string>>, and Expression<Func<object, object, bool>> respectively.
An anonymous method:
delegate (object p, object q) { return string.Concat(p, q); }
// ^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// parameter list body
Here are two examples of lambda conversion:
Func<object, object, bool> aDelegate = (o1, o2) => object.Equals(o1, o2);
Expression<Func<object, object, bool>> anExpressionTree = (o1, o2) => object.Equals(o1, o2);
In method group conversion, the parameters and method body are specified by overload resolution. To simplify a bit, the compiler looks at the methods with the indicated name and chooses the correct overload based on the context. For example, consider these overloads of SquareMethod:
int SquareMethod(int a) { return a * a; }
double SquareMethod(double a) { return a * a; }
These statements involve method group conversion and overload resolution:
Func<int, int> squareAnInt = SquareMethod;
Func<double, double> squareADouble = SquareMethod;
Finally, statement lambdas cannot be translated to expression trees:
Action<object> anAction = o => { Console.WriteLine(o); };
Func<object, int> aFunc = o =>
{
var s = (o ?? "").ToString();
Console.WriteLine(s);
return s.Length;
};
The C# language specification (somewhat confusingly) uses the term "anonymous function" to cover both lambda expressions and anonymous methods. Anonymous functions can be implicitly converted to a compatible delegate type, and so can method groups. Therefore, if we have a delegate type called DelegateType, and a declaration/assignment like this:
DelegateType d = [something];
Then [something] can be a method group or an anonymous function. In other words, it can be a method group, an anonymous method or a lambda expression.
So, your correction to the book's text would be better to say "in place of a method group", but I would say
A lambda expression is an unnamed method that, like a named method group, can be used to create a delegate instance.
I might also add
In some cases, a lambda expression can be used to create an expression tree rather than a delegate instance.
Basically a delegate is nothing but an object that knows how to call a specific method. So a delegate instance literally acts as a delegate for the caller: the caller invokes the delegate, and then the delegate calls the target method.

Implicit delegate casting

I would like to know if there is some way to cast method group, anonymous method or lambda expression to System.Delegate without knowing exact delegate type, like
var d = ()=>{};
dynamic d = ()=>{};
Delegate d = ()=>{};
I need a way that would work for any method with any parameters and return type and not using reflection.
Thanks for your answers.
No it is not possible, because a delegate must have a single defined type, but multiple delegates can have the same signature. This makes the delegate type ambiguous - the compiler would have no way of robustly selecting an appropriate type in such a statement. Note that delegate instances of matching-signatures but different types are not interchangeable. For example, is:
i => (i % 2) == 0
A Func<int,bool>, or a Predicate<int> ? Or something else? Note that the number of generic arts is irrelevant; an Action and ThreadStart and MethodInvoker are all just void non-generic parameterless delegates.
Additionally, there's an added complication / ambiguity because lambdas can also be compiled to expression trees, not just delegates:
Func<int, bool> x = i => (i % 2) == 0;
Expression<Func<int, bool>> y = i => (i % 2) == 0;
Expression trees are radically different to delegates.

Why does "Func<bool> test = value ? F: F" not compile?

I have seen similar questions to this, but they involve different types so I think this is a new question.
Consider the following code:
public void Test(bool value)
{
// The following line provokes a compiler error:
// "Type of conditional expression cannot be determined because there is
// no implicit conversion between 'method group' and 'method group".
Func<bool> test = value ? F : F;
}
public bool F()
{
return false;
}
Now, according to the C# 3.0 Standard,
The second and third operands of the
?: operator control the type of the
conditional expression. Let X and Y be
the types of the second and third
operands. Then,
If X and Y are the same type, then
this is the type of the conditional
Otherwise, if an implicit conversion
(§6.1) exists from X to Y, but not
from Y to X, then Y is the type of the
conditional expression. Otherwise, if
an implicit conversion (§6.1) exists
from Y to X, but not from X to Y, then
X is the type of the conditional
expression. Otherwise, no expression
type can be determined, and a
compile-time error occurs.
It seems to me that in my sample code, X and Y must be of the same type, since they are the selfsame entity, Func. So why does it not compile?
The question was changed significantly, so my original answer is a bit off by now.
However, the problem is essentially the same. I.e. there could be any number of matching delegate declarations for F and since there is no implicit conversion between two identical delegate declarations the type of F cannot be converted to Func<bool>.
Likewise, if you declare
private delegate void X();
private delegate void Y();
private static void Foo() {}
You cannot do
X x = Foo;
Y y = x;
Original answer:
It doesn't work because method groups cannot be assigned to an implicitly typed variable.
var test = Func; doesn't work either.
The reason being that there could be any number of delegate types for Func. E.g. Func matches both of these declarations (in addition to Action)
private delegate void X();
private delegate void Y();
To use implicitly typed variables with method groups, you need to remove the ambiguity by casting.
See archil's answer for a concrete example of one way to fix this. That is, he shows what the corrected code might look like [assuming the delegate you desire to match is Action].
var test = value ? (Action)Func: (Action)Func;
Actually, type of method is expressed by delegate it matches. System.Action that i used to cast methods to, is the delegate with signature returning void and taking no parameters - it matches your Func() method. And now your test will know that it is type of System.Action. Delegates are something like interfaces for methods. Take a look at http://msdn.microsoft.com/en-us/library/ms173171(v=vs.80).aspx

Why can't an anonymous method be assigned to var?

I have the following code:
Func<string, bool> comparer = delegate(string value) {
return value != "0";
};
However, the following does not compile:
var comparer = delegate(string value) {
return value != "0";
};
Why can't the compiler figure out it is a Func<string, bool>? It takes one string parameter, and returns a boolean. Instead, it gives me the error:
Cannot assign anonymous method to an
implicitly-typed local variable.
I have one guess and that is if the var version compiled, it would lack consistency if I had the following:
var comparer = delegate(string arg1, string arg2, string arg3, string arg4, string arg5) {
return false;
};
The above wouldn't make sense since Func<> allows only up to 4 arguments (in .NET 3.5, which is what I am using). Perhaps someone could clarify the problem. Thanks.
UPDATE: This answer was written over ten years ago and should be considered to be of historical interest; in C# 10 the compiler will infer some delegate types.
Others have already pointed out that there are infinitely many possible delegate types that you could have meant; what is so special about Func that it deserves to be the default instead of Predicate or Action or any other possibility? And, for lambdas, why is it obvious that the intention is to choose the delegate form, rather than the expression tree form?
But we could say that Func is special, and that the inferred type of a lambda or anonymous method is Func of something. We'd still have all kinds of problems. What types would you like to be inferred for the following cases?
var x1 = (ref int y)=>123;
There is no Func<T> type that takes a ref anything.
var x2 = y=>123;
We don't know the type of the formal parameter, though we do know the return. (Or do we? Is the return int? long? short? byte?)
var x3 = (int y)=>null;
We don't know the return type, but it can't be void. The return type could be any reference type or any nullable value type.
var x4 = (int y)=>{ throw new Exception(); }
Again, we don't know the return type, and this time it can be void.
var x5 = (int y)=> q += y;
Is that intended to be a void-returning statement lambda or something that returns the value that was assigned to q? Both are legal; which should we choose?
Now, you might say, well, just don't support any of those features. Just support "normal" cases where the types can be worked out. That doesn't help. How does that make my life easier? If the feature works sometimes and fails sometimes then I still have to write the code to detect all of those failure situations and give a meaningful error message for each. We still have to specify all that behaviour, document it, write tests for it, and so on. This is a very expensive feature that saves the user maybe half a dozen keystrokes. We have better ways to add value to the language than spending a lot of time writing test cases for a feature that doesn't work half the time and doesn't provide hardly any benefit in cases where it does work.
The situation where it is actually useful is:
var xAnon = (int y)=>new { Y = y };
because there is no "speakable" type for that thing. But we have this problem all the time, and we just use method type inference to deduce the type:
Func<A, R> WorkItOut<A, R>(Func<A, R> f) { return f; }
...
var xAnon = WorkItOut((int y)=>new { Y = y });
and now method type inference works out what the func type is.
Only Eric Lippert knows for sure, but I think it's because the signature of the delegate type doesn't uniquely determine the type.
Consider your example:
var comparer = delegate(string value) { return value != "0"; };
Here are two possible inferences for what the var should be:
Predicate<string> comparer = delegate(string value) { return value != "0"; }; // okay
Func<string, bool> comparer = delegate(string value) { return value != "0"; }; // also okay
Which one should the compiler infer? There's no good reason to choose one or the other. And although a Predicate<T> is functionally equivalent to a Func<T, bool>, they are still different types at the level of the .NET type system. The compiler therefore cannot unambiguously resolve the delegate type, and must fail the type inference.
Eric Lippert has an old post about it where he says
And in fact the C# 2.0 specification
calls this out. Method group
expressions and anonymous method
expressions are typeless expressions
in C# 2.0, and lambda expressions join
them in C# 3.0. Therefore it is
illegal for them to appear "naked" on
the right hand side of an implicit
declaration.
Different delegates are considered different types. e.g., Action is different than MethodInvoker, and an instance of Action can't be assigned to a variable of type MethodInvoker.
So, given an anonymous delegate (or lambda) like () => {}, is it an Action or a MethodInvoker? The compiler can't tell.
Similarly, if I declare a delegate type taking a string argument and returning a bool, how would the compiler know you really wanted a Func<string, bool> instead of my delegate type? It can't infer the delegate type.
The following points are from the MSDN regarding Implicitly Typed Local Variables:
var can only be used when a local variable is declared and initialized in the same statement; the variable cannot be initialized to null, or to a method group or an anonymous function.
The var keyword instructs the compiler to infer the type of the variable from the expression on the right side of the initialization statement.
It is important to understand that the var keyword does not mean "variant" and does not indicate that the variable is loosely typed, or late-bound. It just means that the compiler determines and assigns the most appropriate type.
MSDN Reference: Implicitly Typed Local Variables
Considering the following regarding Anonymous Methods:
Anonymous methods enable you to omit the parameter list.
MSDN Reference: Anonymous Methods
I would suspect that since the anonymous method may actually have different method signatures, the compiler is unable to properly infer what the most appropriate type to assign would be.
My post doesn't answer the actual question, but it does answer the underlying question of :
"How do I avoid having to type out some fugly type like Func<string, string, int, CustomInputType, bool, ReturnType>?" [1]
Being the lazy/hacky programmer that I am, I experimented with using Func<dynamic, object> - which takes a single input parameter and returns an object.
For multiple arguments, you can use it like so:
dynamic myParams = new ExpandoObject();
myParams.arg0 = "whatever";
myParams.arg1 = 3;
Func<dynamic, object> y = (dynObj) =>
{
return dynObj.arg0.ToUpper() + (dynObj.arg1 * 45); //screw type casting, amirite?
};
Console.WriteLine(y(myParams));
Tip: You can use Action<dynamic> if you don't need to return an object.
Yeah I know it probably goes against your programming principles, but this makes sense to me and probably some Python coders.
I'm pretty novice at delegates... just wanted to share what I learned.
[1] This assumes that you aren't calling a method that requires a predefined Func as a parameter, in which case, you'll have to type that fugly string :/
Other answers were correct at the time they were written, but starting from C# 10.0 (from 2021), the compiler can infer a suitable delegate type (like some Func<...>, Action<...> or generated delegate type) in such cases.
See C# 10 Features - Lambda improvements.
var comparer = delegate(string value) {
return value != "0";
}; // OK in C# 10.0, picks 'Func<string, bool>' in this case
Of course the more usual syntax is to us =>, so:
var comparer = (string value) => {
return value != "0";
}; // OK in C# 10.0, picks 'Func<string, bool>' in this case
How is about that?
var item = new
{
toolisn = 100,
LangId = "ENG",
toolPath = (Func<int, string, string>) delegate(int toolisn, string LangId)
{
var path = "/Content/Tool_" + toolisn + "_" + LangId + "/story.html";
return File.Exists(Server.MapPath(path)) ? "<a style=\"vertical-align:super\" href=\"" + path + "\" target=\"_blank\">execute example</a> " : "";
}
};
string result = item.toolPath(item.toolisn, item.LangId);

Categories

Resources