重写方法上的 C# 可选参数

Question

似乎在 .NET Framework 中，当您重写方法时，可选参数存在问题。下面代码的输出是： “bb” “啊啊” 。但我期望的输出是： “bb” “bb” .有没有办法解决这个问题。我知道可以通过方法重载来解决这个问题，但想知道这样做的原因。该代码在 Mono 中也运行良好。

class Program
{
    class AAA
    {
        public virtual void MyMethod(string s = "aaa")
        {
            Console.WriteLine(s);
        }

        public virtual void MyMethod2()
        {
            MyMethod();
        }
    }

    class BBB : AAA
    {
        public override void MyMethod(string s = "bbb")
        {
            base.MyMethod(s);
        }

        public override void MyMethod2()
        {
            MyMethod();
        }
    }

    static void Main(string[] args)
    {
        BBB asd = new BBB();
        asd.MyMethod();
        asd.MyMethod2();
    }
}

Answer 1

您可以通过调用以下方法来消除歧义：（

this.MyMethod();

在 MyMethod2() 中）

是否是一个 bug 很棘手；不过，它看起来确实不一致。 ReSharper 会警告您不要更改覆盖中的默认值（如果这有帮助）；p 当然，ReSharper 也 会告诉您 this. 是多余的，并提供为您删除它...这会改变行为 - 所以 ReSharper 也并不完美。

我承认，它看起来确实可以被视为编译器错误。我需要非常仔细查看才能确定……当你需要埃里克时他在哪里，是吗？

---

编辑：

这里的关键点是语言规范；让我们看看§7.5.3：

例如，方法调用的候选集不包括标记为 override 的方法（第 7.4 节），并且如果派生类中的任何方法适用，则基类中的方法不是候选方法（第 7.6.5.1 节）。

（事实上​​，§7.4 明确地忽略了 override 方法）

这里存在一些冲突......它指出，如果有适用的方法，则不使用 base 方法派生类 - 这将引导我们使用派生方法，但同时，它表示不考虑标记为override的方法。

但是，§7.5.1.1 则指出：

对于类中定义的虚拟方法和索引器，参数列表是从函数成员的最具体的声明或重写中选取的，从接收器的静态类型开始，并搜索其基类。

然后 §7.5.1.2 解释了如何在调用时评估这些值：

在函数成员调用（第 7.5.4 节）的运行时处理期间，参数列表的表达式或变量引用按从左到右的顺序计算，如下所示：

...（剪断）...

当带有相应可选参数的函数成员省略参数时，将隐式传递函数成员声明的默认参数。因为它们始终是常数，所以它们的求值不会影响其余参数的求值顺序。

这明确强调了它正在查看参数列表，该列表先前在 §7.5.1.1 中定义为来自最具体的声明或覆盖。这似乎是第 7.5.1.2 节中提到的“方法声明”，因此传递的值应该是从最派生的类型一直到静态类型。

这表明：csc 有一个错误，它应该使用派生版本（“bbb bbb”），除非它受到限制（通过base.，或转换为基类型）来查看基方法声明（第 7.6.8 节）。

Answer 2

这里值得注意的一件事是每次都会调用重写的版本。将覆盖更改为：

public override void MyMethod(string s = "bbb")
{
  Console.Write("derived: ");
  base.MyMethod(s);
}

输出为：

derived: bbb
derived: aaa

类中的方法可以执行以下一项或两项操作：

1. 它定义一个接口供其他代码调用。
2. 它定义了调用时要执行的实现。

它可能不会同时执行两者，因为抽象方法只执行前者。

在 BBB 中，调用 MyMethod() 调用 AAA 中定义的方法。

由于 BBB 中存在重写，因此调用该方法会导致调用 BBB 中的实现。

现在，AAA 中的定义告知调用代码两件事（好吧，还有其他一些在这里并不重要的事情）。

1. 签名void MyMethod(string)。
2. （对于支持它的语言）单个参数的默认值为 "aaa"，因此在编译 MyMethod() 形式的代码时，如果没有方法匹配 MyMethod() 可以找到，您可以将其替换为对 `MyMethod("aaa") 的调用。

所以，这就是 BBB 中的调用所做的：编译器看到对 MyMethod() 的调用，但没有找到方法 MyMethod()但确实找到了一个方法MyMethod(string)。它还发现在定义它的地方有一个默认值“aaa”，因此在编译时它将其更改为对 MyMethod("aaa") 的调用。

在 BBB 内部，AAA 被视为定义 AAA 方法的位置，即使在 BBB 中被覆盖，以便它们可以被覆盖。

在运行时，使用参数“aaa”调用 MyMethod(string)。因为有一个被重写的形式，即被调用的形式，但它不是用“bbb”调用的，因为该值与运行时实现无关，而是与编译时定义有关。

添加 this. 会更改检查的定义，从而更改调用中使用的参数。

编辑：为什么这对我来说似乎更直观。

就我个人而言，由于我谈论的是直观的，所以它只能是个人的，我发现这更直观，原因如下：

如果我正在编码 BBB ，那么无论是调用还是重写 MyMethod( string)，我认为这是“做 AAA 东西” - 这是 BBB 的“做 AAA 东西” “，但它正在做AAA 东西都是一样的。因此，无论是调用还是重写，我都会意识到 AAA 定义了 MyMethod(string)。

如果我调用使用 BBB 的代码，我会想到“使用 BBB stuff”。我可能不太清楚 AAA 最初定义的是哪个，我可能会认为这仅仅是一个实现细节（如果我没有同时使用 AAA ） > 接口附近）。

编译器的行为符合我的直觉，这就是为什么当我第一次阅读这个问题时，我觉得 Mono 有一个错误。经过考虑，我看不出其中任何一个如何比另一个更好地实现指定的行为。

不过，就这一点而言，在保持个人水平的同时，我永远不会将可选参数与抽象、虚拟或重写方法一起使用，并且如果重写其他人的方法，我会匹配他们的参数。

Answer 3

这对我来说看起来像是一个错误。我相信它已经明确指定了，
并且它的行为应该与您调用相同的方式
带有显式 this 前缀的方法。

我已将示例简化为仅使用单个虚拟
方法，并显示调用了哪个实现以及
参数值是什么：

using System;

class Base
{
    public virtual void M(string text = "base-default")
    {
        Console.WriteLine("Base.M: {0}", text);
    }   
}

class Derived : Base
{
    public override void M(string text = "derived-default")
    {
        Console.WriteLine("Derived.M: {0}", text);
    }

    public void RunTests()
    {
        M();      // Prints Derived.M: base-default
        this.M(); // Prints Derived.M: derived-default
        base.M(); // Prints Base.M: base-default
    }
}

class Test
{
    static void Main()
    {
        Derived d = new Derived();
        d.RunTests();
    }
}

所以我们需要担心的是 RunTests 中的三个调用。
前两次调用的规范的重要部分是部分
7.5.1.1，讲的是查找对应参数时要使用的参数列表：

对于类中定义的虚拟方法和索引器，参数
列表是从最具体的声明或覆盖中选取的
函数成员的静态类型开始
接收器，并搜索其基类。

第 7.5.1.2 节：

当带有相应可选参数的函数成员省略参数时，将隐式传递函数成员声明的默认参数。

“相应的可选参数”是将 7.5.2 与 7.5.1.1 联系起来的位。

对于 M() 和 this.M()，该参数列表应该是
Derived 中作为接收者静态类型的为 Derived，
事实上，你可以看出编译器会处理
作为编译早期的参数列表，就好像您
使参数在 Derived.M() 中强制，两者
调用失败 - 因此 M() 调用需要参数
Derived 中的默认值，但随后忽略它！

事实上，情况会变得更糟：如果您为
Derived 中的参数，但在 Base 中强制使用该参数，调用
M() 最终使用 null 作为参数值。如果不出意外的话
我想说这证明这是一个错误： null 值无法出现
来自任何有效的地方。 （它是 null 因为它是默认值
string 类型的值；它总是只使用默认值
参数类型。）

规范第 7.6.8 节涉及 base.M()，其中表示
以及与非虚拟行为一样，该表达式也被视为
作为((Base) this).M();所以对于基本方法来说这是完全正确的
用于确定有效参数列表。这意味着
最后一行是正确的。

只是为了让那些想要看到上述真正奇怪的错误的人变得更容易，其中使用了未在任何地方指定的值：

using System;

class Base
{
    public virtual void M(int x)
    {
        // This isn't called
    }   
}

class Derived : Base
{
    public override void M(int x = 5)
    {
        Console.WriteLine("Derived.M: {0}", x);
    }

    public void RunTests()
    {
        M();      // Prints Derived.M: 0
    }

    static void Main()
    {
        new Derived().RunTests();
    }
}

Answer 4

您是否尝试过：

 public override void MyMethod2()
    {
        this.MyMethod();
    }

所以您实际上告诉您的程序使用重写方法。

Answer 5

这种行为确实很奇怪；我不清楚这是否实际上是编译器中的错误，但可能是。

昨晚校园下了相当大的雪，西雅图不太擅长应对雪。我的公共汽车今天早上没有运行，因此我无法进入办公室比较 C# 4、C# 5 和 Roslyn 对于此案例的看法以及他们是否不同意。一旦我回到办公室并且可以使用适当的调试工具，我将在本周晚些时候尝试发布分析。

Answer 6

这可能是由于歧义造成的，编译器优先考虑基类/超类。下面对 BBB 类的代码进行了更改，添加了对 this 关键字的引用，给出了输出“bbb bbb”：

class BBB : AAA
{
    public override void MyMethod(string s = "bbb")
    {
        base.MyMethod(s);
    }

    public override void MyMethod2()
    {
        this.MyMethod(); //added this keyword here
    }
}

它暗示的一件事是您应该始终使用 this 关键字作为最佳实践。

我会担心基本方法和子方法中的这种歧义甚至没有引发编译器警告（如果不是错误），但如果确实如此，我想这是看不见的。

====== =================================================== ==========

编辑：请考虑以下链接中的示例摘录：

http://geekswithblogs.net/BlackRabbitCoder/archive/2011/07/28/c.net-little-pitfalls-default-parameters-are-compile-time-substitutions.aspx

<一个href="http://geekswithblogs.net/BlackRabbitCoder/archive/2010/06/17/c-Optional-parameters---pros-and-pitfalls.aspx" rel="nofollow">http://geekswithblogs.net /BlackRabbitCoder/archive/2010/06/17/c-可选参数---pros-and-pitfalls.aspx

陷阱：可选参数值是编译时的
使用可选参数时，需要记住一件事，并且只需要记住一件事。如果您牢记这一点，您很可能会很好地理解并避免使用它们的任何潜在陷阱：
有一件事是这样的：可选参数是编译时的语法糖！

陷阱：注意继承和接口实现中的默认参数

现在，第二个潜在的陷阱与继承和接口实现有关。我将用一个谜题来说明：

   1: public interface ITag 
   2: {
   3:     void WriteTag(string tagName = "ITag");
   4: } 
   5:  
   6: public class BaseTag : ITag 
   7: {
   8:     public virtual void WriteTag(string tagName = "BaseTag") { Console.WriteLine(tagName); }
   9: } 
  10:  
  11: public class SubTag : BaseTag 
  12: {
  13:     public override void WriteTag(string tagName = "SubTag") { Console.WriteLine(tagName); }
  14: } 
  15:  
  16: public static class Program 
  17: {
  18:     public static void Main() 
  19:     {
  20:         SubTag subTag = new SubTag();
  21:         BaseTag subByBaseTag = subTag;
  22:         ITag subByInterfaceTag = subTag; 
  23:  
  24:         // what happens here?
  25:         subTag.WriteTag();       
  26:         subByBaseTag.WriteTag(); 
  27:         subByInterfaceTag.WriteTag(); 
  28:     }
  29: } 

会发生什么？好吧，即使每种情况下的对象都是 SubTag，其标签是“SubTag”，你也会得到：

1: SubTag
2：基本标签
3：ITag

但请记住确保：

不要在现有默认参数集的中间插入新的默认参数，这可能会导致不可预测的行为，不一定会引发语法错误 - 添加到列表末尾或创建新方法。
在继承层次结构和接口中使用默认参数时要格外小心——根据预期用途选择最合适的级别来添加默认值。

=================================================== =======================

Answer 7

我认为这是因为这些默认值在编译时是固定的。如果您使用反射器，您将在 BBB 中看到 MyMethod2 的以下内容。

public override void MyMethod2()
{
    this.MyMethod("aaa");
}

Answer 8

总体同意@Marc Gravell 的观点。

不过，我想提一下，这个问题在 C++ 世界中已经足够老了（http://www .devx.com/tips/Tip/12737），答案看起来像“与在运行时解析的虚拟函数不同，默认参数是静态解析的，即在编译时解析的。”因此，这种 C# 编译器行为由于一致性而被故意接受，尽管它似乎是出乎意料的。

Answer 9

无论哪种方式都需要修复

我肯定会认为它是一个错误，要么因为结果是错误的，要么如果结果是预期的那么编译器不应该让你将它声明为“覆盖”，或者在至少提供警告。

我建议您向 Microsoft.Connect 报告此问题

这是对是错？

但是关于这是否是预期行为，让我们首先分析一下对此的两种观点。

考虑我们有以下代码：

void myfunc(int optional = 5){ /* Some code here*/ } //Function implementation
myfunc(); //Call using the default arguments

有两种方法来实现它：

1. 可选参数被视为重载函数，导致以下结果：

   void myfunc(int optional){ /* 这里有一些代码*/ } //函数实现
   无效 myfunc(){ myfunc(5); } //默认参数实现
   myfunc(); //使用默认参数调用
   

2. 默认值嵌入到调用者中，从而产生以下代码：

   void myfunc(int optional){ /* 这里有一些代码*/ } //函数实现
   myfunc(5); //调用并嵌入默认参数
   

两种方法之间有很多差异，但我们首先看一下 .Net 框架如何解释它。

1. 在.Net中，您只能使用包含相同数量参数的方法来重写方法，但不能使用包含更多参数的方法来重写方法，即使它们都是可选的（这会导致导致调用与重写的方法具有相同的签名），例如您有：

   class bassClass{ public virtual void someMethod()}
   class subClass :bassClass{ public override void someMethod()} //合法
   //以下内容是非法的，尽管它会被称为 someMethod();
   //类子类：bassClass{公共覆盖无效someMethod（int可选= 5）} 
   

2. 您可以使用另一个不带参数的方法重载具有默认参数的方法，（这会产生灾难性的影响，因为我稍后会讨论），所以下面的代码是合法的：

   void myfunc(int optional = 5){ /* 这里有一些代码*/ } //带默认值的函数
   void myfunc(){ /* 这里有一些代码*/ } //无参数
   myfunc(); //调用哪个？，没有参数的那个！
   

3. 当使用反射时必须始终提供默认值。

所有这些都足以证明.Net采取了第二次实现，因此OP看到的行为是正确的，至少根据.Net而言。

.Net 方法的问题

然而，.Net 方法确实存在问题。

1. 一致性

   • 就像OP的问题一样，当覆盖继承方法中的默认值时，结果可能是不可预测的

   • 当默认值的原始植入发生更改时，并且由于调用者不必重新编译，我们最终可能会得到不再有效的默认值

   • 反射要求您提供默认值，调用者不必知道该值

2. 破坏代码

   • 当我们有一个带有默认参数的函数并且后来添加一个没有参数的函数时，所有调用现在都将路由到新函数，从而破坏所有现有代码，而不会发出任何通知或警告！

   • 类似的情况也会发生，如果我们稍后去掉不带参数的函数，那么所有调用都会自动路由到带有默认参数的函数，同样不会有任何通知或警告！尽管这可能不是程序员的本意

   • 此外，它不一定是常规实例方法，扩展方法也会出现同样的问题，因为不带参数的扩展方法将优先于带默认参数的实例方法！

总结：远离可选参数，并使用替代重载（正如 .NET 框架本身所做的那样）