将.net Func <T>转换为.net Expression <Func <T >>

Question

使用方法调用从lambda到Expression很容易...public void GimmeExpression(Expression<Func<T>> expression){    ((MemberExpression)expression.Body).Member.Name; // "DoStuff"}public void SomewhereElse(){    GimmeExpression(() => thing.DoStuff());}但是我只想在少数情况下将Func转换为表达式...public void ContainTheDanger(Func<T> dangerousCall){    try     {        dangerousCall();    }    catch (Exception e)    {        // This next line does not work...        Expression<Func<T>> DangerousExpression = dangerousCall;        var nameOfDanger =             ((MemberExpression)dangerousCall.Body).Member.Name;        throw new DangerContainer(            "Danger manifested while " + nameOfDanger, e);    }}public void SomewhereElse(){    ContainTheDanger(() => thing.CrossTheStreams());}无效的行给了我编译时错误Cannot implicitly convert type 'System.Func<T>' to 'System.Linq.Expressions.Expression<System.Func<T>>'。显式强制转换不能解决这种情况。有我可以忽略的设施吗？

Answer 1

哦，这根本不容易。Func<T>表示通用delegate而不是表达式。如果有任何方法可以这样做（由于优化程序和编译器完成的其他工作，某些数据可能会被丢弃，因此可能无法恢复原始表达式），这将是在实时拆卸IL的过程。并推断表达式（绝非易事）。将lambda表达式视为data（Expression<Func<T>>）是编译器的一项神奇功能（基本上，编译器在代码中构建表达式树，而不是将其编译为IL）。

相关事实

这就是为什么将lambda推到极限的语言（例如Lisp）通常更易于实现为解释器。在这些语言中，代码和数据本质上是同一件事（即使在运行时也是如此），但是我们的芯片无法理解这种形式的代码，因此我们必须通过在可以理解该机器的基础上构建一个解释器来模拟这种机器（像语言一样由Lisp做出的选择）或在某种程度上牺牲了功能（代码不再完全等于数据）（C＃做出的选择）。在C＃中，编译器通过允许在编译时将lambda解释为code（Func<T>）和data（Expression<Func<T>>）的方式，给人一种将代码视为数据的错觉。

Answer 2

  private static Expression<Func<T, bool>> FuncToExpression<T>(Func<T, bool> f)  

    {  

        return x => f(x);  

    }