为什么ref和out不足以消除C＃中的重载歧义？

如何解决为什么ref和out不足以消除C＃中的重载歧义？

| 例如，为什么不将方法“ 0”视为“ 1”的重载？为什么out相同？

解决方法

这个问题的前提是错误的。

 Max(int x,int y)
 Max(ref int x,ref int y) 
 Max(out int x,out int y)

是名为Max的方法的全部重载。但是，请注意，任何给定的类定义中只能存在最后两个中的一个。根据规范§3.6：方法的签名由方法的名称，类型参数的数量以及每个形式参数的类型和种类（值，引用或输出）组成，并按从左到右的顺序考虑。为此，以形式形参类型出现的方法的任何类型形参不是由其名称标识，而是由其在方法的类型实参列表中的序号位置标识。方法的签名具体不包括返回类型，可能为最右边的参数指定的“ 5”修饰符，也不包括可选的类型参数约束。 [...] 尽管out和ref参数修饰符被认为是签名的一部分，但是以单个类型声明的成员不能仅靠by7ѭ和out来区别签名。如果将两个成员声明为具有相同签名的相同类型，则在将两个方法中带有“ 2”修饰符的所有参数都更改为“ 7”修饰符时，将具有相同的签名，则会发生编译时错误。出于签名匹配的其他目的（例如隐藏或覆盖），“ 7”和“ 2”被视为签名的一部分，并且彼此不匹配。（此限制是为了使C＃程序可以轻松转换为在公共语言基础结构（CLI）上运行，而后者没有提供定义仅在ѭ7和out中不同的方法的方法。） , ref和out是同一件事。 CLR不区分两者。 C＃语言正在与众不同。对于CLR，只有ref。 , 语言设计师决定以这种方式创建它。我怀疑（这只是我的观点）是由于必须指定ref和out以减少混淆。该语言可以很容易地设计为不需要显式指定ref/out，而让编译器隐式地执行它，但这会引起混淆。类似地，进行这些重载将阻止以这种方式编写其他语言（因为CLR不仅是C＃），而且还会增加许多用户的整体困惑，并且不清楚将调用哪种方法。 , 让我们写一些代码：

static void M1(int y)
{
    Console.WriteLine(\"val\");
}

static void M1(ref int y)
{
    Console.WriteLine(\"ref\");
}

//static void M1(out int y)  // compile error
//{
//    Console.WriteLine(\"out\");
//}

static void Main2()
{
    int a = 3;

    M1(a);
    M1(ref a);
//    M1(out a);

}

这只是ref和ѭ2only版本之间的冲突。注释掉out参数方法，它会按预期编译并运行：输出为val和ref。 ,

public void Max(int x,int y)          
//No Error
public void Max(ref int x,ref int y)  
//No Error
public void Max(out int x,out int y)  
//cannot define an overloaded method that differs only on parameter modifiers \'out\' and \'ref\'

第一种和第二种方法可以重载。但是第二和第三种方法不能重载，因为在运行时对ref和out的处理不同，但在编译时对它们的处理相同。

为什么ref和out不足以消除C＃中的重载歧义？

如何解决为什么ref和out不足以消除C＃中的重载歧义？

解决方法

相关推荐