c#：为什么不使用方法签名解析这个不明确的枚举引用？

Question

考虑以下代码：

namespace ConsoleApplication
{
    using NamespaceOne;
    using NamespaceTwo;

    class Program
    {
        static void Main(string[] args)
        {
            // Compilation error.  MyEnum is an ambiguous reference
            MethodNamespace.MethodClass.Frobble(MyEnum.foo);
        }
    }
}

namespace MethodNamespace
{
    public static class MethodClass
    {
        public static void Frobble(NamespaceOne.MyEnum val)
        {
            System.Console.WriteLine("Frobbled a " + val.ToString());
        }   
    }
}

namespace NamespaceOne
{
    public enum MyEnum
    {
        foo, bar, bat, baz
    }
}

namespace NamespaceTwo
{
    public enum MyEnum
    {
        foo, bar, bat, baz
    }
}

编译器抱怨 MyEnum 在对 Frobble() 的调用中是一个不明确的引用。由于调用什么方法没有歧义，因此人们可能期望编译器根据方法签名解析类型引用。为什么不呢？

请注意，我并不是说编译器应该这样做。我相信有充分的理由证明事实并非如此。我只是想知道这是什么原因。

Answer 1

保罗是对的。在 C# 的大多数情况下，我们“从内到外”进行推理。

调用什么方法没有歧义，

它对你来说是明确的，但与编译器无关。重载解析的任务是确定方法组Frobble是否可以解析为给定已知参数的特定方法。 如果我们无法确定参数类型是什么，那么我们甚至不会尝试进行重载解析。

恰好只包含一个方法的方法组在这方面并不特殊。在重载决策成功之前，我们仍然需要有充分的论据。

在某些情况下，我们会从“由外到内”进行推理，即在对 lambda 进行类型分析时。这样做会使重载解析算法变得极其复杂，并且给编译器带来了一个需要解决的问题，在糟糕的情况下，这个问题至少是 NP-HARD。但在大多数情况下，我们希望避免这种复杂性和费用； 通过在父表达式之前分析子表达式来分析表达式，而不是相反。

更一般地说：C# 不是一种“当程序不明确时使用启发式方法来猜测程序员可能的意思”的语言。这是一种“通知开发人员他们的程序不清楚并且可能损坏”的语言。语言中旨在尝试解决不明确情况的部分（例如重载解析或方法类型推断或隐式类型数组）经过精心设计，以便算法具有明确的规则，将版本控制和其他现实世界的方面考虑在内。一旦程序的某个部分不明确，就立即退出是我们实现这一设计目标的一种方法。

如果您更喜欢一种更“宽容”的语言来尝试弄清楚您的意思，那么 VB 或 JScript 可能是更适合您的语言。它们更多的是“按我的意思做，而不是按我说的做”的语言。

Answer 2

我相信这是因为 C# 编译器 通常不会回溯。

Answer 3

NamespaceOne 和 NamespaceTwo 在同一代码文件中定义。这相当于将它们放在不同的代码文件中并通过 using 语句引用它们。

在这种情况下，您就会明白为什么名称会发生​​冲突。您在两个不同的命名空间中具有同名的枚举，并且编译器无法猜测它是哪一个，即使 Frobble 有一个 NamespaceOne.MyEnum 参数。而不是

MethodNamespace.MethodClass.Frobble(MyEnum.foo)

使用

MethodNamespace.MethodClass.Frobble(NamespaceOne.MyEnum.foo)