Should LINQ lambda expression parameters be reused in a second lambda?

Question

Following this question I would like to know if the reuse of lambda parameter expression instances should be considered good or bad?

I sometimes get a complete LINQ expression tree where the same lambda parameter instance is local correctly used in a second, nonnested lambda:

// class Person { public int AProp { get; set; } public bool BProp { get; set; }}
var lparam = Expression.Parameter(typeof(Person),"x");
var lambda1 = (Expression<Func<Person,int>>)Expression.Lambda(Expression.Property(lparam, "AProp"), lparam);
var lambda2 = (Expression<Func<Person,bool>>)Expression.Lambda(Expression.Property(lparam, "BProp"), lparam);
var source = (new Person[0]).AsQueryable();
var query = source.Where(lambda2).OrderBy(lambda1); 

So the declaration of the same lambda parameter instance lparam is correct for both lambda1 and lambda2.

It is just that this shared lambda parameter instance forces IQueryProvider implementations to not associate additional global meaning based on the pure lambda parameter reference, as the same parameter could need to be interpreted differently during processing of a different lambda. Also, you will not get this kind of expression tree (or should I say graph?) from LINQ by using

Expression<Func<Person,int>> lambda3 = x => x.AProp;
Expression<Func<Person,bool>> lambda4 = x => x.BProp;

because there will be different parameter instances of (Person x) for both lambda expressions. The same goes for

var query = source.Where(x => x.BProp).OrderBy(x => x.AProp);

or

var query = from x in source where x.BProp order by x.AProp select x;

It also makes the expression tree to be rather a graph.

Is that style of reuse of parameter instances considered good or bad? So far, I have not found a clear answer to this from the authorities.

Answer 1

I would not share a parameter object between two disjoint lambdas.

First, let's not make false economies here. Objects are cheap and you are not going to be making a hundred thousand of these. (And if you are, you probably have larger problems to solve.)

Second, as you note, sharing referentially identical parameter objects across unrelated lambdas means that code which analyzes those lambda expression trees is required to understand that the parameter object has a different meaning in different contexts. That seems like a bug waiting to happen.

Third, one imagines that someday you might want to take two expression trees:

x => Foo(x);
y => Bar(y);

and from them build a third, say:

(x,y) => Foo(x) && Bar(y);

If x and y are actually both the same parameter object then you have a problem on your hands:

(x,x) => Foo(x) && Bar(x);  // Huh?

On the other side, StriplingWarrior's answer points out that if you have

x => Foo(x);
x => Bar(x);

then it is easier to combine them as

x => Foo(x) && Bar(x);

because then you do not need to rewrite anything.

Basically, it just seems like a risky move with no truly compelling upside, so why do it?