“默认接口方法（）”特性提案将允许C#、F#及其他.NET语言实现有限形式的。受Java的默认方法启发，库作者将可以向已发布的接口中添加新方法而不破坏向后兼容性，其中也包括默认实现。

对于这个人们热议的特性，争论双方都固执己见。在这一点上，什么 都没变。最新消息是，这可能只是一个.NET Core特性。

在讨论“”提案时，来自微软的Phillip Carter写道：

\

我得说一下，默认接口方法确实为我们提供了一个.NET运行时支持的方式，用于支持#243（在某种程度上）。不过，这项修改仅限于.NET Core，因为修改桌面CLR支持底层运行时特性的可能性微乎其微。因此，就像C#一样，F#也将会有一个只有在你使用了CoreCLR是才有效的特性。

\\

[…]

\\

默认接口方法需要修改运行时。这也意味着需要进行检查，看看特定的运行时是否支持这个特性：

\\

已推出的.NET Framework版本现在还没有支持这个特性的，它们将来提供支持的可能性也微乎其微，因为那会有破坏现在广泛存在的已有应用的风险。.NET Core最终将在其运行时中包含这个特性，但是，现在还没有完全确定，它是否也会包含在.NET Framework、mono或UWP运行时的某个未来版本中。正如@jnm2提到的那样，除非每一种支持.NET Standard的运行时都包含这个特性，否则你就无法在.NET Standard中使用它们。它也不在即将到来的.NET Standard 2.1的计划中。

\\

我考虑的是，从长远规划的角度看，我们所能做的不仅仅是在面对这样一种结构时保持冷静。这个特性是从C#复制的？恐怕不是。一个成熟的traits/typeclasses系统？那需要花时间进行恰当的设计。它如何与已有的东西如SRTP合理共存？对于现在的接口、将来的接口、函数即接口、常规的泛型、SRTP及其他东西，该如何考虑？但至少，在我看来，实现某种东西的机制即将到来，因此，在一个比较高的层面上考虑下还是有好处的，那是什么东西，它会有哪种行为，它如何与这方面的现有特性合理共存。

\

在中，Joseph Musser做出了以下回应：

\

作为库作者，这意味着，如果其中一个库的目标不是.NET Framework或者在.NET Framework上运行的一个.NET Standard版本，那么DIM在现如今这种情况下就无助于API的演化。添加一个接口方法仍然是一项破坏性修改。

\

对此，Thomas Levesque补充说，“对于该特性而言，由于库是最重要的使用场景，那会使得整个特性几乎没用……”

查看英文原文：