为什么c#要求调用者为具有可选参数的方法提供实际参数值?

摘自Eric Lippert自己的话:

也就是说，它们认为默认值以某种方式"嵌入"到被。

实际上，默认值被嵌入到调用者;上面的代码被调用方未受影响，调用方变为

M("{0}", false);

这个事实的结果是，如果你改变的调用者不重新编译的库方法的默认值在那个库中，调用者不会因为默认值已更改。如果你发布了一个新版本的方法M将默认值更改为true，这对那些调用者无关紧要。直到带有一个参数的M调用者被重新编译，它总是通过假的。

这可能是件好事。将默认值从false更改为true打破变化，有人可能会说，现有的调用者应该不受突发变化的影响。

这是一个相当严重的版本问题，也是主要原因之一为什么我们拖了这么久才给c#添加默认参数。的这里的教训是要仔细考虑与长有关的场景记住这个词。如果您怀疑您将更改默认值你希望调用者在不重新编译的情况下获取更改，不要在参数列表中使用默认值;进行两次重载，其中参数较少的一方调用另一方。

来源:可选参数角用例，第四部分(完整系列)

至于为什么这在Scala中是不同的:也许c#中不存在技术限制。如果你浏览了关于可选参数的4篇文章，你会注意到它们有许多需要记住的角落案例。

如果这不是一个技术上的限制，它很可能是一个管理上的限制。正如经常指出的那样:

这是我们如何设计c# 4的

首先，我们列出了我们能想到的所有可能的特征添加到语言中。

然后我们把这些特性归类为"这很糟糕，我们绝不能这样做"，"这太棒了，我们必须这样做"，"这很好，但我们不要这样做"这次一定要做!

然后我们看了一下我们需要多少预算来设计，实施，测试，记录、装运和维护"必须拥有"的物品;特点和发现我们100%超出了预算。

我们把一些东西从"必须拥有"中移了出来桶到"好"have"桶。

我们花在设计，实现，测试，记录或维护一个好的功能X是我们不能花在很棒上的一分钟A、B、C、D、E、F和g的特征，我们必须无情地将它们按优先顺序排列我们只做最好的功能。索引属性将要友善，但友善远远不够好到得到实现。