C# variable scoping not consistent?

Question

C# is quite nit-picking when it comes to variable scoping. How is it possible that it accepts this code:

class Program
{
    int x = 0;

    void foo()
    {
        int x = 0;
        x = 1;

        Console.WriteLine(x);
    }
}

If you ask me, that's an obvious naming conflict. Still the compiler (VS 2010) accepts it. Why?

Answer 1

Because the rule is that if a conflict exists between a local variable and a class member, the local variable has higher precedence.

Answer 2

This is not ambiguous the local will be the variable that is assumed to reffed to in your function. If you need to get the class variable this.x allows the name resolution.

Answer 3

There is no naming conflict. The compiler always takes the nearest/least scope variable.

In this case, thats the x variable you declare in foo. Every variable can be accessed in a specific way, so theres no naming conflict.

If you want to access the outer x you can use this.x.

Answer 4

This is not a naming conflict: in C#, local variables take precedence over instance variables with the same name, because their scope is narrower.

When the compiler matches a name reference to a name declaration, it uses the matching declaration with the narrowest scope

See documentation on Reference Matching for detailed information on the subject.

Answer 5

The C# 4.0 spec says this about scope hiding through nesting:

3.7.1.1 Hiding through nesting

Name hiding through nesting can occur as a result of nesting namespaces or types within namespaces, as a result of nesting types within classes or structs, and as a result of parameter and local variable declarations. In the example

class A {
    int i = 0;
    void F() {
        int i = 1;
    }
    void G() {
        i = 1;
    }
}

within the F method, the instance variable i is hidden by the local variable i, but within the G method, i still refers to the instance variable.

When a name in an inner scope hides a name in an outer scope, it hides all overloaded occurrences of that name.

In the example

class Outer {
    static void F(int i) {}
    static void F(string s) {}
    class Inner
    {
        void G() {
            F(1);           // Invokes Outer.Inner.F
            F("Hello");     // Error
        }
        static void F(long l) {}
    }
}

the call F(1) invokes the F declared in Inner because all outer occurrences of F are hidden by the inner declaration. For the same reason, the call F("Hello") results in a compile-time error.

Answer 6

The rules for C# name hiding are quite complex. The language allows the case you mention, but disallows many similar cases. See

http://ericlippert.com/2009/11/02/simple-names-are-not-so-simple/

for some information on this complicated subject.

To address your specific question: the compiler certainly could detect that conflict. In fact, it does detect that conflict:

class P
{
    int x;
    void M()
    {
        x = 123; // The author intends "this.x = 123;"
        int x = 0;
    }
}

The equivalent C++ program would be legal C++, because in C++ a local variable comes into scope at the point of its declaration. In C#, a local variable is in scope throughout its entire block, and using it before its declaration is illegal. If you try compiling this program you get:

error CS0844: Cannot use local variable 'x' before it is declared.
The declaration of the local variable hides the field 'P.x'.

See: the local declaration hides the field. The compiler knows it. So why in your case is it not an error to hide a field?

Let's suppose for the sake of argument that it should be an error. Should this also be an error?

class B
{
    protected int x;
}
class D : B
{
    void M()
    {
        int x;
    }
}

The field x is a member of D via inheritance from B. So this should also be an error, right?

Now suppose you have this program produced by Foo Corporation:

class B
{
}

and this program produced by Bar Corporation:

class D : B
{
    void M()
    {
        int x;
    }
}

That compiles. Now suppose Foo Corp updates their base class and ships a new version out to you:

class B
{
    protected int x;
}

You're telling me that every derived class that contains a local variable named x should now fail to compile?

That would be horrid. We have to allow local variables to shadow members.

And if we're going to allow locals to shadow members of base classes, it would seem awfully strange to not allow locals to shadow members of classes.