Add conversion from the System Expression to the Light Expression to allow hoisted system expression embedding in the larger light expression

[dadhi]

Has a different goal than the #259

[waf]

This would be incredible to have. It would allow us to expose public methods that accept an Expression<Func<T>> parameter and the compile it into a larger Light Expression. So the consumer would just get the benefit of the faster compilation and execution, without needing to take on a direct dependency to FastExpressionCompiler, right?

I suppose it should be possible to use the ExpressionVisitor class to build this (either external to FastExpressionCompiler or as part of the library).

[dadhi]

hi @waf,

So the consumer would just get the benefit of the faster compilation and execution, without needing to take on a direct dependency to FastExpressionCompiler, right?

No, it does not work this way. FEC is equally fast for the System Expression and for the LightExpression (except for some rare corner cases).
Where LightExpression is beneficial, is when you need to build the expression. Building the light expression will consume less memory and will be faster. So in the formula Expression Building + Compilation, LE will help to reduce the building phase.
So when converting System Expression to LE you will actually waste additional time and memory.

[dadhi]

@waf Explaining the idea of this issue.

The conversion may be useful when you have the public API accepting the System Expression,
which you want to integrate into much bigger Light Expression. For instance, User may specify the Predicate via expression, so it may be the part of the bigger LightExpression Lambda, Loop or Block or something else.

Currently, this scenario is impossible without realizing of this issue.