title: Why don't non-capturing expression trees that are initialized using lambda expressions get cached?
body: <p>Consider the following class:</p>
  
  <pre><code>class Program
  {
      static void Test()
      {
          TestDelegate&lt;string, int&gt;(s =&gt; s.Length);
  
          TestExpressionTree&lt;string, int&gt;(s =&gt; s.Length);
      }
  
      static void TestDelegate&lt;T1, T2&gt;(Func&lt;T1, T2&gt; del) { /*...*/ }
  
      static void TestExpressionTree&lt;T1, T2&gt;(Expression&lt;Func&lt;T1, T2&gt;&gt; exp) { /*...*/ }
  }
  </code></pre>
  
  <p>This is what the compiler generates (in a <em>slightly</em> less readable way):</p>
  
  <pre><code>class Program
  {
      static void Test()
      {
          // The delegate call:
          TestDelegate(Cache.Func ?? (Cache.Func = Cache.Instance.FuncImpl));
  
          // The expression call:
          var paramExp = Expression.Parameter(typeof(string), "s");
          var propExp = Expression.Property(paramExp, "Length");
          var lambdaExp = Expression.Lambda&lt;Func&lt;string, int&gt;&gt;(propExp, paramExp);
          TestExpressionTree(lambdaExp);
      }
  
      static void TestDelegate&lt;T1, T2&gt;(Func&lt;T1, T2&gt; del) { /*...*/ }
  
      static void TestExpressionTree&lt;T1, T2&gt;(Expression&lt;Func&lt;T1, T2&gt;&gt; exp) { /*...*/ }
  
      sealed class Cache
      {
          public static readonly Cache Instance = new Cache();
  
          public static Func&lt;string, int&gt; Func;
  
          internal int FuncImpl(string s) =&gt; s.Length;
      }
  }
  </code></pre>
  
  <p>This way the delegate passed with the first call is initialized once and reused on multiple <code>Test</code> calls.</p>
  
  <p>However, the expression tree passed with the second call is not reused - a new lambda expression is initialized on each <code>Test</code> call.</p>
  
  <p>Provided it doesn't capture anything and expression trees being immutable, what would be the problem with caching the expression tree as well?</p>
  
  <p><strong>Edit</strong></p>
  
  <p>I think I need to clarify why I think the expression trees are fit to be cached.</p>
  
  <ol>
  <li>The resulting expression tree is known at the compilation time (well, it <em>is</em> created by the compiler).</li>
  <li>They are immutable. So, unlike the array example given by X39 below, an expression tree can't be modified after it's initialized and therefore, is safe to be cached.</li>
  <li>There can be only so many expression trees in a code-base - Again, I'm talking about the ones that can be cached, i.e. the ones that are initialized using lambda expressions (not the ones that are created manually) without capturing any outside state/variable. Auto-interning of string literals would be a similar example.</li>
  <li>They are meant to be traversed - They <em>can</em> be compiled to create a delegate, but that's not their main function. If someone wants a compiled delegate, they can just accept one (a <code>Func&lt;T&gt;</code>, instead of an <code>Expression&lt;Func&lt;T&gt;&gt;</code>). Accepting an expression tree indicates that it's going to be used as a data structure. So, "they should be compiled first" is not a sensible argument against caching of expression trees.</li>
  </ol>
  
  <p>What I'm asking is the potential drawbacks of caching these expression trees. Memory requirements mentioned by svick is a more likely example.</p>