Question

Can this statement be made into 1 lambda expression?

if (filter.SubFormId.HasValue)
{
    query = query.Where(c => c.SubFormId == filter.SubFormId);
}

Answer 1

Be very careful with this kind of query. The where clause is bound to the variable filter, not to the current value.

Original code:

var query = from form in forms select form;
var filter = new Filter();
filter.SubFormId = 123;
if (filter.SubFormId.HasValue)
{
    query = query.Where(c => c.SubFormId == filter.SubFormId);
}
filter = null;
foreach(var matchingForm in query)
{ ... }

That code crashes. The query uses the current value of filter, not the value that it was when the query was made.

Jared’s version does no better:

var query = from form in forms select form;
var filter = new Filter();
filter.SubFormId = 123;
query = query.Where(c => 
  !filter.SubFormId.HasValue || c.SubFormId == filter.SubFormId);
filter = null;
foreach(var matchingForm in query)
{ ... }

That crashes too.

Your version and Jared’s version also have different semantics if the filter is mutated in other ways:

Original code:

var query = from form in forms select form;
var filter = new Filter();
filter.SubFormId = null;
if (filter.SubFormId.HasValue)
{
    query = query.Where(c => c.SubFormId == filter.SubFormId);
}
filter.SubFormId = 123;
foreach(var matchingForm in query)
{ ... }

That matches every form. You never added a Where clause.

Jared’s version does something different:

var query = from form in forms select form;
var filter = new Filter();
filter.SubFormId = null;
query = query.Where(c => 
  !filter.SubFormId.HasValue || c.SubFormId == filter.SubFormId);
filter.SubFormId = 123;
foreach(var matchingForm in query)
{ ... }

That matches only the forms that have subformId equal to 123. Jared’s version matches against the current value of the filter subform Id if there is one, regardless of whether or not there was one when the query was built.

Remember, queries are objects that represent the query. When you execute the query, the query is re-executed from scratch and the clauses in it are evaluated against the current values of the variables that the query closed over, not against a snapshot of the values of the variables as they existed when the query was created. Queries have a live, up-to-date view of variables.

So lets say I also return this query, which allows the query to be evaluated outside of the method. Would this crash since the filter will go out of scope?

Short answer:

no.

Longer answer:

This is a duplicate of this question:

Action/Lambda Expression Memory Management Question

See my answer for details.

Long answer:

You are confusing scope with lifetime — a common error. Scope is purely a compile-time concept; the scope of a local variable is the region of program text in which that variable may be referred to by its name. The lifetime of a variable is purely a runtime concept; the lifetime of a local variable is the period of time during which the storage is known to the garbage collector to be valid.

Scope and lifetime are often connected; while control is logically in a portion of the program text in which a local is in scope, it is known to be alive. Locals used in queries, lambdas, iterator blocks and async blocks have their lifetimes extended so that even when control leaves the scope of the local, the local is still alive. The local stays alive at least until the query, lambda, etc, is dead.

It is possible in some cases that the local stays alive longer, unfortunately; see the linked question above for an example. For an extended discussion of this problem, see this question:

C# Action, Closure, and Garbage Collection