“默认接口方法（ Default Interface Methods ）”特性提案将允许 C#、F#及其他.NET 语言实现有限形式的多继承。受Java 的默认方法启发，库作者将可以向已发布的接口中添加新方法而不破坏向后兼容性，其中也包括默认实现。
对于这个人们热议的特性，争论双方都固执己见。在这一点上，什么 都没变。最新消息是，这可能只是一个.NET Core 特性。
在讨论“ F#中的默认接口方法”提案时，来自微软的 Phillip Carter 写道：
我得说一下，默认接口方法确实为我们提供了一个.NET 运行时支持的方式，用于支持#243（在某种程度上）。不过，这项修改仅限于.NET Core，因为修改桌面 CLR 支持底层运行时特性的可能性微乎其微。因此，就像 C#一样，F#也将会有一个只有在你使用了 CoreCLR 是才有效的特性。
[…]
默认接口方法需要修改运行时。这也意味着需要进行检查，看看特定的运行时是否支持这个特性： https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md#clr-support-api
已推出的.NET Framework 版本现在还没有支持这个特性的，它们将来提供支持的可能性也微乎其微，因为那会有破坏现在广泛存在的已有应用的风险。.NET Core 最终将在其运行时中包含这个特性，但是，现在还没有完全确定，它是否也会包含在.NET Framework、mono 或 UWP 运行时的某个未来版本中。正如 @jnm2 提到的那样，除非每一种支持.NET Standard 的运行时都包含这个特性，否则你就无法在.NET Standard 中使用它们。它也不在即将到来的.NET Standard 2.1 的计划中。
我考虑的是，从长远规划的角度看，我们所能做的不仅仅是在面对这样一种结构时保持冷静。这个特性是从 C#复制的？恐怕不是。一个成熟的 traits/typeclasses 系统？那需要花时间进行恰当的设计。它如何与已有的东西如 SRTP 合理共存？对于现在的接口、将来的接口、函数即接口、常规的泛型、SRTP 及其他东西，该如何考虑？但至少，在我看来，实现某种东西的机制即将到来，因此，在一个比较高的层面上考虑下还是有好处的，那是什么东西，它会有哪种行为，它如何与这方面的现有特性合理共存。
在 C#提案话题中，Joseph Musser 做出了以下回应：
作为库作者，这意味着，如果其中一个库的目标不是.NET Framework 或者在.NET Framework 上运行的一个.NET Standard 版本，那么 DIM 在现如今这种情况下就无助于 API 的演化。添加一个接口方法仍然是一项破坏性修改。
对此，Thomas Levesque 补充说，“对于该特性而言，由于库是最重要的使用场景，那会使得整个特性几乎没用……”
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论