Why can't C# member names be the same as the enclosing type name?

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?

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:

Public Class Class1
    Public Sub Class1()

    End Sub
End Class

In C#, you reference it as:

var class1 = new Class1();
class1.Class1();

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?

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.