From this question: Lambda expression with a void input
I have the following very simple code:
int minutes = () => 9;
I get compiler error:
Cannot convert lambda expression to type 'int' because it is not a
delegate type
I've found several questions about this error but they're all about more specific issues. I actually want to give my lambda a body but thought I'd start simple first to check my syntax:
//I know this is a weird example
int minutes = ()=> { if(x==9) return 9; else return 5;}
From C# guide
A lambda expression is a block of code (an expression or a statement block) that is treated as an object. It can be passed as an argument to methods, and it can also be returned by method calls.
...
Lambda expressions are code that can be represented either as a delegate, or as an expression tree that compiles to a delegate.
That means lambda expression can be represented and can represent different things: delegate or expression tree.
Your expression
() => 9;
can be so many different things, as example
public class C {
delegate int IntDelegate();
public void M() {
Func<int> minutes = () => 9;
IntDelegate minutes2 = () => 9;
Expression<Func<int>> minutesExpression = () => 9;
Expression<IntDelegate> minutesExpression2 = () => 9;
}
}
So what do you want to use?
By the way, because of all that, you can't use var with them.
And you can see how c# compiler work under the hood for different lambda here-> lambda as delegate and expression tree
Related
Fundamentally, is there any difference between a single-line expression lambda and a statement lambda? Take the following code, for example:
private delegate void MyDelegate();
protected static void Main()
{
MyDelegate myDelegate1 = () => Console.WriteLine("Test 1");
MyDelegate myDelegate2 = () => { Console.WriteLine("Test 2"); };
myDelegate1();
myDelegate2();
Console.ReadKey();
}
While I prefer the first because I find the brackets to be ugly, is there anything different between the two (besides the obvious part about requiring brackets for multi-line statements)?
You need statement lambda for multistatement lambdas. In addition statement lambdas are not supported by expression providers like LINQ to SQL. Before .NET 4.0 the .NET Framework did not have support for statement expression trees. This was added in 4.0 but as far as I know no provider uses it.
Action myDelegate1 = () => Console.WriteLine("Test 1");
Expression<Action> myExpression = () => { Console.WriteLine("Test 2") }; //compile error unless you remove the { }
myDelegate1();
Action myDelegate2 = myExpression.Compile();
myDelegate2();
Otherwise they are the same.
Reflector to the rescue! The disassembled code looks like this:
private static void Main(string[] args)
{
MyDelegate myDelegate1 = delegate {
Console.WriteLine("Test 1");
};
MyDelegate myDelegate2 = delegate {
Console.WriteLine("Test 2");
};
myDelegate1();
myDelegate2();
Console.ReadKey();
}
So no, there is no real difference between the two. Be happy.
The two are the same - the first is syntactic sugar to the second and both will compile to the same IL.
No, there is no difference in this example. If the body of the lambda is only one expression, you can drop the brackets. However, once the lambda contains more than one expression, like so:
MyDelegate myDelegate2 = () => {
Console.WriteLine("Test 2");
Console.WriteLine("Test 2");
};
the brackets are mandatory.
If the delegate returns a value, return is necessary in statement lambda as follows.
Func<int, int, bool> foo = (x, y) => { return x == y; };
Func<int, int, bool> goo = (x, y) => x == y;
Personnaly, i prefer the Lambda Expression. The Expression have a value where the Statement does not.
i think the following links can help you :
http://lambda-the-ultimate.org/node/1044
Same for the OP example, but after C# 6.0, allowing you to use same expression syntax to define normal non-lambda methods within a class. For example:
public static double AreaOfTriangle(double itsbase, double itsheight)
{
return itsbase * itsheight / 2;
}
The above code snippet can be written only if the method can be turned into a single expression. In short, it can be used the expression lambda syntax, but not the statement lambda syntax.
public static double
AreaOfTrianglex(double itsbase, double itsheight) => itsbase * itsheight / 2;
From the docs (https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/lambda-expressions):
Statement lambdas, like anonymous methods, cannot be used to create expression trees.
The screenshot says it pretty much.
I have the overloads as seen in the screenshot. When using a string as second parameter the compiler should figure out that the first argument can only be a Func and not an expression.
But the compiler throws an error saying 'A lamda expression with a statement body cannot be converted to an expression tree'.
Why can't the compiler figure out the correct overload?
Explicit cast does not help. What works is when i make a local variable of type Func and then use this instead.
The framework used is FakeItEasy 1.24.0
EDIT:
Here is the code that shows the behavior:
public static void Main(string[] args)
{
//compiler error
A.CallTo(() => Main(A<string[]>.That.Matches(strings =>
{
return true;
}, "description")));
//compiles
Func<string[], bool> predicate = strings =>
{
return true;
};
A.CallTo(() => Main(A<string[]>.That.Matches(predicate, "description")));
Console.ReadLine();
}
The issue is not in the call to Matches. It's in the call to CallTo, which expects an Expression<Action>.
Apparently an Expression not only can't be a lambda expression with a statement body, it also can't contain a lambda expression with a statement body.
(I'm not sure whether your "put the lambda in a local variable" solution will work or whether it just tricks the compiler and will fail at runtime.)
Here's the test I put together:
static void Overloaded(Action a, string param) { }
static void Overloaded(Expression<Action> e) { }
static void CallToAction(Action a) { }
static void CallToExprAc(Expression<Action> a) { }
static void Main(string[] args)
{
// Works
CallToAction(() => Overloaded(() => { int i = 5; }, "hi"));
// Doesn't work - using the Expression overload
CallToAction(() => Overloaded(() => { int i = 5; }));
// Doesn't work - wrapped in an outer Expression
CallToExprAc(() => Overloaded(() => { int i = 5; }, "hi"));
}
Whether your "put the expression-bodied lambda in a local" works is up to how FakeItEasy is implemented. I suspect it'll work here, but something similar in e.g. LINQ-to-SQL wouldn't - it'd just fail at runtime rather than at compile time.
I'm not sure whether this is a compiler bug, a spec bug or desirable behaviour. In section 6.5 of the C# spec we have
Certain lambda expressions cannot be converted to expression tree types: Even though the conversion exists, it fails at compile-time. This is the case if the lambda expression:
• Has a block body
• Contains simple or compound assignment operators
• Contains a dynamically bound expression
• Is async
which doesn't say "contains a lambda expression that cannot be converted to an expression tree type".
Can you say what is the use of the ()=> and =>? I saw this in a code. I did not get any reference for this.
this.Dispatcher.BeginInvoke(()=>
{
//some thing..
};
=> is the lambda operator in C# and is read as "goes to". A lambda expression is an anonymous function and can be used to create a delegate.
Your example takes no arguments as indicated by the empty parens preceding the lambda operator. A lambda expression with one argument might look like this:
n => n.toString()
That expression would return the string representation of n, when invoked. A lambda expression can have multiple arguments as well, contained in parentheses:
(n, f) => n.toString(f)
A common use would be in a Func<T>:
Func<int, string> getString = n => n.toString();
int num = 7;
string numString = getString(num);
This is, of course, a silly example, but hopefully helps to illustrate its use.
This notation is that of a lambda expression which takes no argument. If the lambda expression made use of arguments they would be declared in the empty set of parenthesis as in say...
this.Dispatcher.BeginInvoke((x, y) => { do some' with x and/or y }, 12, somevar);
In a nutshell, lambda expressions allows creating "nameless" functions, right where they are needed.
In the example of the question, the BeginInvoke() method requires its first parameter to be a delegate (a "pointer to a method"), which is exactly what this lambda expression provides.
It's a lambda expression that has no parameters.
Check out this page http://codebetter.com/karlseguin/2008/11/27/back-to-basics-delegates-anonymous-methods-and-lambda-expressions/
If you don’t have any parameters, like in our example, you use empty
paranthesis:
() => {…}
Forgive me if this screams newbie but what does => mean in C#? I was at a presentation last week and this operator (I think) was used in the context of ORM. I wasn't really paying attention to the specifics of syntax until I went back to my notes.
In C# the lambda operator is written "=>" (usually pronounced "goes to" when read aloud). It means that the arguments on the left are passed into the code block (lambda function / anonymous delegate) on the right.
So if you have a Func or Action (or any of their cousins with more type parameters) then you can assign a lambda expression to them rather than needing to instantiate a delegate or have a separate method for the deferred processing:
//creates a Func that can be called later
Func<int,bool> f = i => i <= 10;
//calls the function with 12 substituted as the parameter
bool ret = f(12);
Since nobody mentioned it yet, in VB.NET you'd use the function keyword instead of =>, like so:
dim func = function() true
'or
dim func1 = function(x, y) x + y
dim result = func() ' result is True
dim result1 = func1(5, 2) ' result is 7
It's shorthand for declaring a lambda.
i => i++
is (sort of) the same as writing:
delegate(int i)
{
i++;
}
In the context of:
void DoSomething(Action<int> doSomething)
{
doSomething(1);
}
DoSomething(delegate(int i) { i++; });
//declares an anonymous method
//and passes it to DoSomething
which is (sort of) the same as writing:
void increment(int i)
{
i++;
}
Just without giving it a name, it allows you to declare a function in-line, known as an "anonymous" function.
When said aloud the operator is the lambda (goes to) operator which helps to define the anonymous delegate that you're defining in the lambda.
A common place to see this is with an event handler. You will often have a a page load type event that is handled by a lambda with the following code:
this.Loaded += (o, e) => {
// code
}
You've defined a method handling the Loaded event anonymously (it doesn't have a name) by using a lambda expression. It would read as "o, e goes to ... method definition with foo."
This is the "lambda operator", and you read it as "goes to". Say you had the statement:
doSomething(x => x + " hi");
You can replace the "=>" in your mind with this:
doSomething(delegate (string x) { return x + " hi" });
As you can see, it offers a heck of a shorthand. The compiler figures out the type of the variable that you're passing, and allows you to get rid of the function signature and bracketing for the code that you're passing the signature variables into.
It's a lambda operator, part of a lambda expression.
All lambda expressions use the lambda
operator =>, which is read as "goes
to". The left side of the lambda
operator specifies the input
parameters (if any) and the right side
holds the expression or statement
block. The lambda expression x => x *
x is read "x goes to x times x."
It's syntax to declare an anonymous function, known in C# as a "lambda expression."
For example, (int p) => p * 2 represents a function that takes an integer and multiplies it by two.
Once it is compiled, is there a difference between:
delegate { x = 0; }
and
() => { x = 0 }
?
Short answer : no.
Longer answer that may not be relevant:
If you assign the lambda to a delegate type (such as Func or Action) you'll get an anonymous delegate.
If you assign the lambda to an Expression type, you'll get an expression tree instead of a anonymous delegate. The expression tree can then be compiled to an anonymous delegate.
Edit:
Here's some links for Expressions.
System.Linq.Expression.Expression(TDelegate) (start here).
Linq in-memory with delegates (such as System.Func) uses System.Linq.Enumerable. Linq to SQL (and anything else) with expressions uses System.Linq.Queryable. Check out the parameters on those methods.
An Explanation from ScottGu. In a nutshell, Linq in-memory will produce some anonymous methods to resolve your query. Linq to SQL will produce an expression tree that represents the query and then translate that tree into T-SQL. Linq to Entities will produce an expression tree that represents the query and then translate that tree into platform appropriate SQL.
I like Amy's answer, but I thought I'd be pedantic. The question says, "Once it is compiled" - which suggests that both expressions have been compiled. How could they both compile, but with one being converted to a delegate and one to an expression tree? It's a tricky one - you have to use another feature of anonymous methods; the only one which isn't shared by lambda expressions. If you specify an anonymous method without specifying a parameter list at all it is compatible with any delegate type returning void and without any out parameters. Armed with this knowledge, we should be able to construct two overloads to make the expressions completely unambiguous but very different.
But disaster strikes! At least with C# 3.0, you can't convert a lambda expression with a block body into an expression - nor can you convert a lambda expression with an assignment in the body (even if it is used as the return value). This may change with C# 4.0 and .NET 4.0, which allow more to be expressed in an expression tree. So in other words, with the examples MojoFilter happened to give, the two will almost always be converted to the same thing. (More details in a minute.)
We can use the delegate parameters trick if we change the bodies a little bit though:
using System;
using System.Linq.Expressions;
public class Test
{
static void Main()
{
int x = 0;
Foo( () => x );
Foo( delegate { return x; } );
}
static void Foo(Func<int, int> action)
{
Console.WriteLine("I suspect the anonymous method...");
}
static void Foo(Expression<Func<int>> func)
{
Console.WriteLine("I suspect the lambda expression...");
}
}
But wait! We can differentiate between the two even without using expression trees, if we're cunning enough. The example below uses the overload resolution rules (and the anonymous delegate matching trick)...
using System;
using System.Linq.Expressions;
public class Base
{
public void Foo(Action action)
{
Console.WriteLine("I suspect the lambda expression...");
}
}
public class Derived : Base
{
public void Foo(Action<int> action)
{
Console.WriteLine("I suspect the anonymous method...");
}
}
class Test
{
static void Main()
{
Derived d = new Derived();
int x = 0;
d.Foo( () => { x = 0; } );
d.Foo( delegate { x = 0; } );
}
}
Ouch. Remember kids, every time you overload a method inherited from a base class, a little kitten starts crying.
In the two examples above there's no difference, zero.
The expression:
() => { x = 0 }
is a Lambda expression with statement body, so it can't be compiled as an expression tree. In fact it doesn't even compile because it needs a semicolon after 0:
() => { x = 0; } // Lambda statement body
() => x = 0 // Lambda expression body, could be an expression tree.
Amy B is correct. Note that there can be advantages to using expression trees. LINQ to SQL will examine the expression tree and convert it to SQL.
You can also play tricks with lamdas and expression trees to effectively pass the names of class members to a framework in a refactoring-safe way. Moq is an example of this.
There is a difference
Example:
var mytask = Task.Factory.StartNew(() =>
{
Thread.Sleep(5000);
return 2712;
});
mytask.ContinueWith(delegate
{
_backgroundTask.ContinueTask(() =>lblPercent.Content = mytask.Result.ToString(CultureInfo.InvariantCulture));
});
And I replace with lambda:(error)
var mytask = Task.Factory.StartNew(() =>
{
Thread.Sleep(5000);
return 2712;
});
mytask.ContinueWith(()=>
{
_backgroundTask.ContinueTask(() =>lblPercent.Content = mytask.Result.ToString(CultureInfo.InvariantCulture));
});
Some basics here.
This is a anonymous method
(string testString) => { Console.WriteLine(testString); };
As anonymous methods do not have names we need a delegate in which we can assign both of these methods or expressions. e.g.
delegate void PrintTestString(string testString); // declare a delegate
PrintTestString print = (string testString) => { Console.WriteLine(testString); };
print();
Same with the lambda expression. Usually we need a delegate to use them
s => s.Age > someValue && s.Age < someValue // will return true/false
We can use a func delegate to use this expression.
Func< Student,bool> checkStudentAge = s => s.Age > someValue && s.Age < someValue ;
bool result = checkStudentAge ( Student Object);