lambda 表达式中的事件 - C# 编译器错误？

Question

我正在考虑使用lambda表达式来允许事件以强类型的方式连接，但中间有一个侦听器，例如给定以下类

class Producer
{
    public event EventHandler MyEvent;
}

class Consumer
{
    public void MyHandler(object sender, EventArgs e) { /* ... */ }
}

class Listener
{
    public static void WireUp<TProducer, TConsumer>(
        Expression<Action<TProducer, TConsumer>> expr) { /* ... */ }
}

事件将被连接为：

Listener.WireUp<Producer, Consumer>((p, c) => p.MyEvent += c.MyHandler);

但是这会产生编译器错误：

CS0832：表达式树可能不包含赋值运算符

现在乍一看这似乎是合理的，特别是在 阅读有关为什么表达式树不能包含赋值的解释。 然而，尽管是 C# 语法，+= 并不是一个赋值，而是对 Producer::add_MyEvent 方法的调用，正如我们从 CIL 中看到的那样如果我们只是正常连接事件，就会产生这样的结果：

L_0001: newobj instance void LambdaEvents.Producer::.ctor()
L_0007: newobj instance void LambdaEvents.Consumer::.ctor()
L_000f: ldftn instance void LambdaEvents.Consumer::MyHandler(object, class [mscorlib]System.EventArgs)
L_0015: newobj instance void [mscorlib]System.EventHandler::.ctor(object, native int)
L_001a: callvirt instance void LambdaEvents.Producer::add_MyEvent(class [mscorlib]System.EventHandler)

所以在我看来，这是一个编译器错误，因为它抱怨不允许赋值，但没有发生赋值，只是一个方法调用。 或者我错过了什么......？

编辑：

请注意，问题是“此行为是编译器错误吗？”。 抱歉，如果我不清楚我在问什么。

编辑2

在阅读了 Inferis 的答案后，他说“此时 += 被认为是赋值”，这确实有一定道理，因为此时编译器可能不知道它是将转变为 CIL。

但是，我不允许编写显式方法调用形式：

Listener.WireUp<Producer, Consumer>(
    (p, c) => p.add_MyEvent(new EventHandler(c.MyHandler)));

给出：

CS0571：“Producer.MyEvent.add”：无法显式调用运算符或访问器

因此，我想问题归结为 += 在 C# 事件上下文中的实际含义。 它意味着“调用此事件的添加方法”还是意味着“以尚未定义的方式添加到此事件”。 如果是前者，那么在我看来这是一个编译器错误，而如果是后者，那么它有点不直观，但可以说不是一个错误。 想法？

Answer 1

在规范第 7.16.3 节中，+= 和 -= 运算符被称为“事件赋值”，这无疑使其听起来像赋值运算符。 事实上，它位于第 7.16 节（“赋值运算符”）内，这是一个相当大的提示:)从这个角度来看，编译器错误是有道理的。

不过，我同意它的限制过于严格，因为表达式树完全有可能表示 lambda 表达式给出的功能。

我怀疑语言设计者采用了“限制性更强但操作符描述更一致”的方法，恐怕会以牺牲此类情况为代价。

Answer 2

+= 是一个赋值，无论它做什么（例如添加一个事件）。 从解析器的角度来看，它仍然是一个赋值。

你试过了吗

Listener.WireUp<Producer, Consumer>((p, c) => { p.MyEvent += c.MyHandler; } );

Answer 3

实际上，就编译器而言，它是一个赋值。
+= 运算符已重载，但编译器此时并不关心这一点。 毕竟，您是通过 lambda 生成一个表达式（该表达式在某一时刻将被编译为实际代码），而不是真正的代码。

所以编译器所做的是：创建一个表达式，将 c.MyHandler 添加到 p.MyEvent 的当前值，并将更改后的值存储回 p.MyEvent。 所以你实际上是在做一项作业，即使最终你没有做。

您是否希望 WireUp 方法采用表达式而不仅仅是操作？

Answer 4

为什么要使用Expression类？ 将代码中的 Expression> 更改为简单的 Action 并且所有内容都应该按您的意愿工作。 您在这里所做的就是强制编译器将 lambda 表达式视为表达式树而不是委托，并且表达式树确实不能包含此类赋值（它被视为赋值，因为我相信您正在使用 += 运算符）。 现在，lambda 表达式可以转换为任一形式（如 [MSDN][1] 中所述）。 通过简单地使用委托（这就是 Action 类的全部），这样的“分配”是完全有效的。 我可能误解了这里的问题（也许有一个特定的原因需要使用表达式树？），但幸运的是，解决方案似乎确实如此简单！

编辑：是的，我现在从评论中更好地理解了你的问题。 有什么理由不能只将 p.MyEvent 和 c.MyHandler 作为参数传递给 WireUp 方法并在 WireUp 方法中附加事件处理程序（对我来说，从设计的角度来看这似乎也更好）...会这不是消除了对表达式树的需要吗？ 我认为无论如何，最好避免使用表达式树，因为与委托相比，它们往往相当慢。

Answer 5

我认为问题是，除了 Expression 对象之外，从编译器的角度来看，表达式树不是静态类型的。 MethodCallExpression 和朋友不会公开静态类型信息。

尽管编译器知道表达式中的所有类型，但在将 lambda 表达式转换为表达式树时，此信息会被丢弃。 （看看为表达式树生成的代码）

尽管如此，我还是会考虑将其提交给微软。