Lambda expression arguments for Enumerable and Queryable extension methods

Question

A lambda expression is an anonymous method, which under the covers is a delegate so I can do something like this:

 delegate bool Foo(int x);

 Foo bar = x => x == 1;

Passing this delegate to an Enumerable extension method makes perfect sense, as the typical expected argument is a Func, which is shorthand for a delegate:

 public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate);

However, I am unclear about how it is possible to pass in the delegate to a Queryable extension method like this one:

 public static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate);

This method expects an Expression<TDelegate> argument, but it is perfectly legal to pass in a lambda expression. What is the mechanism that coerces the lambda expression into Expression<TDelegate> so that it may be consumed?

I am familiar with the fact that Queryable methods build out expression trees for parsing by providers, I'm just curious about this one aspect that isn't immediately obvious to me.

UPDATE

I'm becoming less ignorant about my ignorance. Lambda expressions aren't delegates, but can be used to create either delegates or expressions:

 Expression<Func<int, bool>> foo = c => c == 1;

Does the compiler infer the type based on the context? I'm guessing that must be the case, as this isn't legal:

var foo = c => c == 1;

Answer 1

This is described in the specification:

4.6 Expression Tree Types

If a conversion exists from a lambda expression to a delegate type D, a conversion also exists to the expression tree type Expression<D>. Whereas the conversion of a lambda expression to a delegate type generates a delegate that references executable code for the lambda expression, conversion to an expression tree type creates an expression tree representation of the lambda expression. Expression trees are efficient in-memory data representations of lambda expressionsand make the structure of the lambda expressiontransparent and explicit

So there is a conversion from a lambda to a compatible expression tree type, and the compiler emits the equivalent expression tree instead of creating a delegate.

Answer 2

Quite simply you can't. However, to make IQueryable methods useful, VS2008 and above include a clever compiler trick. That a lambda expression that is a single statement may be assignable to both a delegate, and an Expression<TDelegate>. The compiler normally will hoist the expression and make a method.

But for an assignment to an Expression<TDelegate> it breaks down the statements into their syntactic meaning and turns that into an expression tree.

e.g.

Func<int,int> func = x=>x*x;
Expression<Func<int,int>> expression = x=>x*x;

The first one will probably be turned into a static method with a garbled name something like::

private static int <B012>SomeMethod(int x){
   return x*x;
}

Where as the second statement will be transformed into something like::

ParameterExpression paramX = Expression.Parameter(typeof(int));
Expression<Func<int,int>> expression = Expression.Lambda<Func<int,int>>(
     Expression.Multiply(paramX,paramX),paramX);

But you can not do::

expression = func;

This is not valid, as func is a delegate. You can do this though::

func=expression.Compile()

Which compiles the expressions into a func.

**Note the suggested transformations may not be a 100% correct.

The reason they did this was to allow LINQ-to-Objects (Basically Map/Reduce from other language) to share the same friendly syntax as LINQ-To-Providers. So you can write a statement that means the same thing but can change where the filtering and transformation happens. GetEmployees().Where(e=>e.LastName=="Smith") Can read the same, but could in theory be describing doing the filtering on this box, or an the database, or parsing an xml file or any number of various things.

Answer 3

I believe this has to do with how the query is built on an IQueryable. The method requires an expression tree because it can be looked inside and structured to match a more optimized (potentially) query or map more closely to the underlying data source. So simply passing in a Func would allow only for execution, whereas an Expression<Func> allows for expression trees which can be observed and executed.

Also, probably more closely answering your exact question, check this SO post out.