为什么 C# 成员名称不能与封闭类型名称相同？
在 C# 中，以下代码无法编译：
class Foo {
public string Foo;
}
问题是：为什么？
更确切地说，我知道这无法编译，因为（我引用）：
成员名称不能与其封闭类型相同
好的，很好。我明白了，我不会再这样做了，我保证。
但我真的不明白为什么编译器拒绝采用与封闭类型同名的任何字段。阻止我这样做的根本问题是什么？
In C#, the following code doesn't compile:
class Foo {
public string Foo;
}
The question is: why?
More exactly, I understand that this doesn't compile because (I quote):
member names cannot be the same as their enclosing type
Ok, fine. I understand that, I won't do it again, I promise.
But I really don't understand why the compiler refuses to take any field having the same name as an enclosing type. What is the underlying issue that prevents me to do that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
严格来说，这是 C# 施加的限制，很可能是为了语法方便。构造函数有一个方法体，但它在 IL 中的成员条目表示为“.ctor”，并且它的元数据与普通方法略有不同（在 Reflection 类中，ConstructorInfo 派生自 MethodBase，而不是 MethodInfo。）我不相信尽管我还没有尝试过，但 .NET 存在限制，无法创建与外部类型同名的成员（甚至是方法）。
我很好奇，所以我确认这不是 .NET 的限制。在 VB 中创建以下类：
在 C# 中，将其引用为：
Strictly speaking, this is a limitation imposed by C#, most likely for convenience of syntax. A constructor has a method body, but its member entry in IL is denoted as ".ctor" and it has slightly different metadata than a normal method (In the Reflection classes, ConstructorInfo derives from MethodBase, not MethodInfo.) I don't believe there's a .NET limitation that prevents creating a member (or even a method) with the same name as the outer type, though I haven't tried it.
I was curious, so I confirmed it's not a .NET limitation. Create the following class in VB:
In C#, you reference it as:
因为 Foo 被保留作为构造函数的名称。
因此，如果您的代码被允许 - 您会如何称呼构造函数？
即使可以通过将构造函数视为特殊情况并将新规则引入方法/成员绑定来做到这一点 - 这会是一个好主意吗？在某些时候这将不可避免地导致混乱。
Because Foo is reserved as the name of the constructor.
So if your code was allowed - what would you call the constructor?
Even if it was possible to do this by treating the constructor as a special case and introducing new rules into method / member binding - would it be a good idea? It would inevitably lead to confusion at some point.
因为成员名称与类构造函数的名称冲突？
Because the member name clashes with the name of the class's constructor?
有正确的方法和错误的方法。
为什么 C# 不允许？
因为它没有理由这样做。你为什么要在你的生活中制造如此混乱。
我认为 CLR 允许这样做，正如另一篇文章用 vb.net 示例证明的那样，它不应该受到限制，但我不想基于 CLR 操作的相同规则创建应用程序。抽象使代码更加清晰。我认为这个论点与多重继承具有相同的作用。是的，它可以用某些语言完成，但会引起混乱。因此，我的答案是减少歧义和混乱，并且基于 C# 解析器/编译器。 C# 团队的设计选择。
There is a right way to do it and a wrong way to do it.
Why Doesn't C# allow it?
Because it does not reason to do so. Why would you want to create such confusion in your life.
I think the CLR allows it, as another post proves with a vb.net example and it should not be restricted, but I would not want to create an application based on the same rules that the CLR operates in. The abstraction makes code more clear. I think the argument works on the same level as multiple inheritance. Yes it can be done in some languages, but it causes confusion. My answer therefore would be to reduce ambiguity and confusion and is based in the c# parser/compiler. A design choice by the C# team.