C# variable scoping: 'x' cannot be declared in this scope because it would give a different meaning to 'x'

Question

if(true)
{
    string var = "VAR";
}

string var = "New VAR!";

This will result in:

Error 1 A local variable named 'var' cannot be declared in this scope because it would give a different meaning to 'var', which is already used in a 'child' scope to denote something else.

Nothing earth shattering really, but isn't this just plain wrong? A fellow developer and I were wondering if the first declaration should be in a different scope, thus the second declaration cannot interfere with the first declaration.

Why is C# unable to differentiate between the two scopes? Should the first IF scope not be completely separate from the rest of the method?

I cannot call var from outside the if, so the error message is wrong, because the first var has no relevance in the second scope.

Caltrop

The actual compiler error is - A local variable named 'x' cannot be declared in this scope because it would give a different meaning to 'x', which is already used in a 'parent or current' scope to denote something else. – Swore

Similar to https://mcmap.net/q/297162/-child-scope-amp-cs0136 – Auld

I presume you're using C# 2.0, since var is a keyword in C# 3.0. – Poulin

@IceHeat - looks like you're falling into the trap of assuming that C# is a lot more like C++ than it really is. Try not to reason from what C++ does to what C# does -- that is dangerous territory! – Ivers

Some programmers prefer C++ because C++ has more freedom. Do those freedoms include this scoping issue? – Caltrop

@IceHeat: A lot of the "more freedom" stuff is that C++ assumes that you know what you are doing. If you are a beginner it will allow you to do a lot of crazy stuff without complaining such as this example, while it will give a lot of freedom to an experienced user. I wouldn't say this is a good example of that freedom. – Brune

var is not a reserved keyword of C# 3.0. "var" only means "implicitly type this local variable" when (1) it appears as the type of a local variable declaration (or using block decl, or foreach, or for, and so on) AND (2) when there is not a type named "var" already in scope. C# has never added a reserved keyword since C# 1; all the new keywords are contextual keywords. They only have meaning as keywords when used in the context that gives them that meaning; they are legal identifiers otherwise. – Paigepaik

@John Saunders: Making var a reserved keyword between C# 2.0 and C# 3.0 would have been a breaking change (programs that compiled suddenly don't compile) and language designers are loathe to make such breaking changes; var is a contextual keyword. Other examples added after C# 2.0 include from, select, group, into, orderby, join, let, on, equals, by, ascending and descending. Note that where and in existed in C# 2.0 (for constraints and foreach statements, respectively) but gained additional context in C# 3.0. – Darbies

It is useful when you want to 'snick in' some code with minimal side effects, as you are then sure, it is not going to conflict with other code. I use it quite often when the deadline is around the corner. – Illtimed

Answer 1

The issue here is largely one of good practice and preventing against inadvertent mistakes. Admittedly, the C# compiler could theoretically be designed such that there is no conflict between scopes here. This would however be much effort for little gain, as I see it.

Consider that if the declaration of var in the parent scope were before the if statement, there would be an unresolvable naming conflict. The compiler simply does not differentiate between the following two cases. Analysis is done purely based on scope, and not order of declaration/use, as you seem to be expecting.

The theoretically acceptable (but still invalid as far as C# is concerned):

if(true)
{
    string var = "VAR";
}

string var = "New VAR!";

and the unacceptable (since it would be hiding the parent variable):

string var = "New VAR!";

if(true)
{
    string var = "VAR";
}

are both treated precisely the same in terms of variables and scopes.

Now, is there any actual reason in this secenario why you can't just give one of the variables a different name? I assume (hope) your actual variables aren't called var, so I don't really see this being a problem. If you're still intent on reusing the same variable name, just put them in sibling scopes:

if(true)
{
    string var = "VAR";
}

{
    string var = "New VAR!";
}

This however, while valid to the compiler, can lead to some amount of confusion when reading the code, so I recommend against it in almost any case.

Acceptor

Of course the compiler would be able to differentiate the two scopes, the inner variable would only hide the outer, and make it unreachable. – Brune

Yeah exactly - it's disallowed simply because it can lead to confusion/is considered bad design practice. – Acceptor

well seen from the IL view point Im pretty sure the if{} scope doesn't exist so it would mean having the compiler do tricks for the value of potential confusion, so if im correct it's not actively disallowed but passively. The needed feature is simply not implemented – Aboard

By the way, you said in a comment on a deleted post that a conditional statement creates a scope. It certainly does not. A block creates a scope. Numerous statements do create scopes -- for, foreach, using, try/catch/finally, and so on. However, the conditional statement is not one of them; the scope created is created by the block, not by the conditional. – Paigepaik

@Eric: Trust you to point something like that out. :) You are, of course, right, though it's a rather subtle point. It is effectively the curly brackets that signify a block, with the notable exceptions you pointed out, that signify a block. Correct me if I'm wrong, but if statements with one-line actions do not contain child scope(s)? – Acceptor

Answer 2

isn't this just plain wrong?

No, this is not wrong at all. This is a correct implementation of section 7.5.2.1 of the C# specification, "Simple names, invariant meanings in blocks".

The specification states:

---

For each occurrence of a given identifier as a simple-name in an expression or declarator, within the local variable declaration space of that occurrence, every other occurrence of the same identifier as a simple-name in an expression or declarator must refer to the same entity. This rule ensures that the meaning of a name is always the same within a given block, switch block, for-, foreach- or using-statement, or anonymous function.

---

Why is C# unable to differentiate between the two scopes?

The question is nonsensical; obviously the compiler is able to differentiate between the two scopes. If the compiler were unable to differentiate between the two scopes then how could the error be produced? The error message says that there are two different scopes, and therefore the scopes have been differentiated!

Should the first IF scope not be completeley seperate from the rest of the method?

No, it should not. The scope (and local variable declaration space) defined by the block statement in the consequence of the conditional statement is lexically a part of the outer block which defines the body of the method. Therefore, rules about the contents of the outer block apply to the contents of the inner block.

I cannot call var from outside the if, so the error message is wrong, because the first var has no relevance in the second scope.

This is completely wrong. It is specious to conclude that just because the local variable is no longer in scope, that the outer block does not contain an error. The error message is correct.

The error here has nothing to do with whether the scope of any variable overlaps the scope of any other variable; the only thing that is relevant here is that you have a block -- the outer block -- in which the same simple name is used to refer to two completely different things. C# requires that a simple name have one meaning throughout the block which first uses it.

For example:

class C 
{
    int x;
    void M()
    { 
        int x = 123;
    }
}

That is perfectly legal; the scope of the outer x overlaps the scope of the inner x, but that is not an error. What is an error is:

class C 
{
    int x;
    void M()
    { 
        Console.WriteLine(x);
        if (whatever)
        {
            int x = 123;
        }
    }
}

because now the simple name "x" means two different things inside the body of M -- it means "this.x" and the local variable "x". It is confusing to developers and code maintainers when the same simple name means two completely different things in the same block, so that is illegal.

We do allow parallel blocks to contain the same simple name used in two different ways; this is legal:

class C 
{
    int x;
    void M()
    { 
        if (whatever)
        {
            Console.WriteLine(x);
        }
        if (somethingelse)
        {
            int x = 123;
        }
    }
}

because now the only block that contains two inconsistent usages of x is the outer block, and that block does not directly contain any usage of "x", only indirectly.

Paigepaik

@Eric: I feel like, among other things, blogs.msdn.com/ericlippert/archive/2009/08/03/… is relevant here. – Foxed

Good point; though in fact the issue of whether we're talking about the block as a local variable declaration space, or the block as a scope of a local variable, is pretty much irrelevant to the question. The problem appears to be about declaration space, since the declaration is flagged. But in fact it is about scope -- we have two entities which are both looked up by their unqualified name successfully, and bound to different entities in the same block. – Paigepaik

The example with field and local variable with the same name being accessed from the same block is probably the single most illuminating with respect to the rationale of this design decision. – Ovenware

Might be just me, but the overall tone of your answer seems a tad aggressive. – Addie

@PhilipWallace: You might be interested in reading my essay on that subject: blogs.msdn.com/b/ericlippert/archive/2008/02/20/… – Paigepaik

Answer 3

This is valid in C++, but a source for many bugs and sleepless nights. I think the C# guys decided that it's better to throw a warning/error since it's, in the vast majority of cases, a bug rather than something the coder actually want.

Here's an interesting discussion on what parts of the specification this error comes from.

EDIT (some examples) -----

In C++, the following is valid (and it doesn't really matter if the outer declaration is before or after the inner scope, it will just be more interesting and bug-prone if it's before).

void foo(int a)
{
    int count = 0;
    for(int i = 0; i < a; ++i)
    {
        int count *= i;
    }
    return count;
}

Now imagine the function being a few lines longer and it might be easy to not spot the error. The compiler never complains (not it the old days, not sure about newer versions of C++), and the function always returns 0.

The behaivour is clearly a bug, so it would be good if a c++-lint program or the compiler points this out. If it's not a bug it is easy to work around it by just renaming the inner variable.

To add insult to injury I remember that GCC and VS6 had different opinions on where the counter variable in for loops belonged. One said it belonged to the outer scope and the other said it didn't. A bit annoying to work on cross-platform code. Let me give you yet another example to keep my line count up.

for(int i = 0; i < 1000; ++i)
{
    if(array[i] > 100)
        break;
}

printf("The first very large value in the array exists at %d\n", i);

This code worked in VS6 IIRC and not in GCC. Anyway, C# has cleaned up a few things, which is good.

Brune