静态解决重载运算符的原因是什么？对我来说，这似乎是一个奇怪的选择——我能想到的唯一优势是性能的小幅提升（但有时 JIT 也可能会避免这种情况），但代价是一些相当不直观的行为——即我基本上必须将操作员转发到一个虚函数来获得想要的行为。
这是刚刚从 C++ 接管还是有其他一些好的原因？
【问题讨论】：
请参阅 Eric Lipperts 的文章 Why are overloaded operators always static in C#?
相反，在面对潜在的语言功能时，我们应该问自己的问题是“该功能的引人注目的好处是否足以证明所有成本都是合理的？”成本远远超过设计、开发、测试、记录和维护功能的普通美元成本。还有更微妙的代价，比如，这个特性会不会让未来改变类型推断算法变得更加困难？这是否会导致我们进入一个如果不引入向后兼容性中断就无法进行更改的世界？以此类推。
在这种特定情况下，引人注目的好处很小。如果您想在 C# 中使用虚拟调度的重载运算符，您可以非常轻松地从静态部分构建一个。 [...]
可以支持基于实例的运算符，但 C# 语言设计者并没有看到与使其正常工作所需的努力相比的巨大收益。
【讨论】：
考虑为引用类型重载运算符时的情况。它可以是运算符两侧的null。
如果运算符是实例方法，它们将不起作用。
【讨论】：
x * y 与解析后的 Scala 中的 x.multiply(y) 没有什么不同。
(int)?10 > (int?)null ... 最后是有道理的，但是仍然造成了一些悲伤:(
x op y 成为x.op(y) 似乎是合乎逻辑的选择）。不过，我可以看到关于不对称的争论。
我想到了两件事，恕我直言，其中任何一件都足以自行破坏交易：
virtual 方法仅根据 this 的运行时类型进行调度。【讨论】：