Just by examination its clear that .SomeProp is dependent on x and x is not deterministic at expression tree parsing time, because its an output of a prior function (where).
my_variable is not an output of any expression in the expression tree so its value might be known at expression tree parsing time, but its quite likely not to be 'baked in' even if it is known because that would prevent the compiled expression tree from being reused, so it will just be treated as an input value into the expression tree evaluation.
I haven't decompiled linq, but you could consider the following expression tree;
ExpressionTree myEx = new ExpressionTree(
new MultiplicationExpression(
new InputVariableExpression("@MyInputVar"),
new ConstantExpression(22)
)
);
To evaluate you might call
Dictionary<string, object> inputVars = new Dictionary<string, object>();
inputVars.Add("@MyInputVar",16);
int result = myEx.Evaluate(inputVars);
The parser might choose to bake in the constant expression, because it 'knows' it cannot change, but consider the following;
ExpressionTree anotherEx = new ExpressionTree(
new AdditionExpression(
myEx,
new InputVariableExpression("@MyNextInputVar")
)
);
This is similar in concept to using a replacement variable in Linq x =>
where myEx is a stored expression tree, but not actually the result of the expression. The expression parser cannot independently know what the value of myEx is until execution time.
Dictionary<string, object> inputVars = new Dictionary<string, object>();
inputVars.Add("@MyInputVar",16);
inputVars.Add("@MyNextInputVar",45);
int result = anotherEx.Evaluate(inputVars);
So this execution code will inherently evaluate myEx
during the evaluation of anotherEx
. If myEx
had only ConstantExpression
element in it, it might be evaluated only once and the result cached, but because it contains an out-of-scope InputVariableExpression
its clear the result of one evaluation cannot be cached for subsequent use.