Static expressions

[IS4Code]

Motivation

Lambda expression trees bound to Expression<T> are constructed every time such an expression is encountered. This is obviously necessary when the expression uses a local variable, but in many (perhaps most) cases, the expression is independent on any variable and can be cached. This can be advantageous to expression rewriters, verifiers, SQL generators etc., as they can also cache the output based on the identity of the expression. The expression tree can be of course moved to a static variable, but this harms readability (especially when the expression is used in code only once).

Rather than changing how expression trees are generated, I think this could be solved generally, for this and other similar cases.

Idea

An expression could be marked static. This serves two purposes:

• It ensures no local variables or parameters are accidentally used in the expression.
• The value of the expression is computed at most once and is not modifiable.

Example

public Expression<Action<T>> GetExpression<T>()
{
    return static a => Console.WriteLine(a.ToString());
}

This can be translated to this:

public Expression<Action<T>> GetExpression<T>()
{
    return Cache0<T>.Value;
}

static class Cache0<T>
{
    public static readonly Expression<Action<T>> Value = a => Console.WriteLine(a.ToString());
}

Details

For every expression marked static, a cache class should be created alongside the method where it is used (copying the generic parameters of it). This leaves the optimal lazy strategy up to the CLR, which only ensures the value is readily available when needed, and handles all necessary synchronization and checks as part of the type initializer.

The expression cannot reference local variables, parameters, and members dependent on this. It also cannot contain another static expression, as it would be redundant. Static local functions can be referenced freely, as well as all other visible static members.

Moving the expression to a nested static class ensures that all static members from the containing class are already initialized when the expression is executed, and so the risks of using uninitialized static fields are minimized. This of course doesn't apply when such an expression is used from within another type initializer.

Exceptions thrown by the static expression are, of course, wrapped in TypeInitializationException.

The type initializer can be marked beforefieldinit or not. This is up to discussion.

Use cases

Any value that can be described as unique, but is local enough not to warrant moving it explicitly to its own static field, can benefit from this. This is even better than static variables found in other languages, as the results of static expressions are not easily modifiable, and are, obviously, directly used when they're needed.

There are other cases which could benefit from this, for example:

• Calculations that cannot be optimized by the compiler (for example involving the Math class).
• Results of typeof (which always calls a method on the result of ldtoken).
• Construction of delegates from static methods.

In other words, all cases where the compiler could be argued to cache the result of the expression, but does not do so (after all, the cost of caching and retrieving the value might be larger than the cost of always having to construct it). If one finds caching the result of those expressions is more performant, than they would have the option to use static there without making significant changes to the code.

[333fred]

static lambdas and delegates are shipping in C# 9. #275

[IS4Code]

Oh, that's good news. I just hope it will cache the result for expression trees as well. This opens the possibility to add this sort of caching for all expressions (seems to be it can be generalized), but I am happy with just expression trees.

[svick]

@IllidanS4 It doesn't cache the result.

[IS4Code]

Seems to me as an oversight. Also what is the use of the <>c class?
Edit: I can answer that myself well anyway: it is supposed to support the normal non-expression tree case, but is not needed here.

I shall take the discussion about caching the trees to that issue.