Develop Reference

How do the compiler know it is out of scope?

Main()
{
int i =0;
...
...
while(true)
{
int k =0;
...
...
}
// K is out of scope..
}
How does the compiler know K is out of scope?

How does the compiler know [that a local variable] is out of scope?
First off, let's carefully define the terms you're using. The scope of a named entity is the region of program text in which it is legal to use the name of the entity without additional qualification of the name.
The scope of a local variable is defined by the specification as the region of program text which is the entire block that immediately contains the declaration.
The compiler determines the scope of the local variable by keeping track of a local declaration space associated with each syntactic block. When we need to resolve a name, we figure out what block the name usage is inside, and consult the related declaration space. Of course, blocks nest and so do local variable declaration spaces, so we might have to consult more than one, in order from inside-to-outside.
The actual data structures we use are straightforward hash tables optimized for fast lookup and filtering on various aspects needed by the compiler. (For example, we sometimes need to look up names but only want to get types, or only methods, and so on.)
Does that answer your question? It's a rather unclear question.

Because as the compiler processes the code it maintains information about each identifier it comes across and each scope it comes across and maintains boundaries for the latter. It knows that K was declared in the while scope and after the scope ends it probably marks the variable as 'no longer in scope' causing any use to be marked as an error.

k is out of scope because the block it was defined in is closed.

I would say it's a meaningless question. K is out of scope because you wrote the program that way: the compiler's entire function is to recognize and translate the programming language, including the lexical scope aspect of it.

Question on C# Variable Scope vs. Other Languages

First of all, let me say that I've never used C# before, and I don't know about it much.
I was studying for my "Programming Languages" exam with Sebesta's "Concepts of Programming Languages 9th ed" book. After I read the following excerpt from "Scope declaration order (on 246th page)", I got a little bit puzzled:
"...For example, in C99, C++, Java the scope of all local variables is from their declarations to the ends of the blocks in which those declarations appear. However, in C# the scope of any variable declared in a block is the whole block, regardless of the position of the declaration in the block, as long as it is not in a nested block. The same is true for methods. Note that C# still requires that all variables be declared before they are used. Therefore, although the scope of a variable extends from the declaration to the top of the block or subprograms in which that declaration appears, the variable still cannot be used above its declaration"
Why did designers of C# make such decision? Is there any specific reason/advantage for such an unusual decision?

This prevents you from doing something such as
void Blah()
{
for (int i = 0; i < 10; i++)
{
// do something
}
int i = 42;
}
The reason is that it introduces the possibility for subtle bugs if you have to move code around, for instance. If you need i before your loop, now your loop is broken.

One example of a benefit of reduced confusion is that if you have a nested block above the variable declaration, the variable declaration will be in effect and prevent the nested block from declaring a variable with the same name.

From the C# Spec
class A
{
int i = 0;
void F() {
i = 1; // Error, use precedes declaration
int i;
i = 2;
}
void G() {
int j = (j = 1); // Valid
}
void H() {
int a = 1, b = ++a; // Valid
}
}
The scoping rules for local variables are designed to guarantee that the meaning of a name used in an expression context is always the same within a block. If the scope of a local variable were to extend only from its declaration to the end of the block, then in the example above, the first assignment would assign to the instance variable and the second assignment would assign to the local variable, possibly leading to compile-time errors if the statements of the block were later to be rearranged.

It's not that strange. As far as variables go, it enforces unique naming better than Java/C++.

Eric Lippert's answer on this related question might be of help.
As Anthony Pegram said earlier, C# enforces this rule because there are cases where rearranging the code can cause subtle bugs, leading to confusion.

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

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.

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.

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.

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.

Variable scope confusion in C#

I have two code samples. The first does not compile, but the second does.
Code Sample 1 (does not compile)
public void MyMethod(){
int i=10;
for(int x=10; x<10; x++) {
int i=10; // Point1: compiler reports error
var objX = new MyOtherClass();
}
var objX = new OtherClassOfMine(); // Point2: compiler reports error
}
I understand why the compiler reports an error at Point1. But I don't understand why it reports an error at Point2. And if you say it is because of the organization inside MSIL, then why does the second code example compile?
Code sample 2 (compiles)
public void MyMethod(){
for(int x=10; x<10; x++) {
int i=10;
var objX = new MyOtherClass();
}
for(int x=10; x<10; x++) {
int i=10;
var objX = new MyOtherClass();
}
}
If the simple rules of variable scope apply in Code Sample 2, then why don't those same rules apply to Code Sample 1?

There are two relevant rules here.
The first relevant rule is:
It is an error for a local variable
declaration space and a nested local
variable declaration space to contain
elements with the same name.
(And another answer on this page calls out another location in the specification where we call this out again.)
That alone is enough to make this illegal, but in fact a second rule makes this illegal.
The second relevant rule in C# is:
For each occurrence of a given
identifier as a simple-name in an
expression or declarator, within the
local variable declaration space,
immediately enclosing block, or
switch-block of that occurrence,
every other occurrence of the same
identifier as a simple-name in an
expression or declarator within the
immediately enclosing block or
switch-block 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.
(UPDATE: This answer was written in 2009; in recent versions of C# this rule has been eliminated because it was considered to be too confusing; the user confusion produced was not worth the small number of bugs that were prevented. See this answer for details.)
You also need to know that a for-loop is treated as though there are "invisible braces" around the whole thing.
Now that we know that, let's annotate your code:
public void MyMethod()
{ // 1
int i=10; // i1
{ // 2 -- invisible brace
for(int x=10; x<10; x++) // x2
{ // 3
int i=10; // i3
var objX = new MyOtherClass(); // objX3
} // 3
} // 2
var objX = new OtherClasOfMine(); // objX1
} // 1
You have three "simple names", i, x and objX. You have five variables, which I've labeled i1, x2, i3, objX3, and objX1.
The outermost block that contains usages of i and objX is block 1. Therefore, within block 1, i and objX must always refer to the same thing. But they do not. Sometimes i refers to i1 and sometimes it refers to i3. Same with objX.
x, however, only ever means x2, in every block.
Also, both "i" variables are in the same local variable declaration space, as are both "objX" variables.
Therefore, this program is an error in several ways.
In your second program:
public void MyMethod()
{ // 1
{ // 2 -- invisible
for(int x=10; x<10; x++) // x2
{ // 3
int i=10; // i3
var objX = new MyOtherClass(); // objX3
} //3
} // 2
{ // 4 -- invisible
for(int x=10; x<10; x++) // x4
{ // 5
int i=10; // i5
var objX = new MyOtherClass(); // objX5
} //5
} // 4
} // 1
Now you have three simple names again, and six variables.
The outermost blocks that first contain a usage of simple name x are blocks 2 and 4. Throughout block 2, x refers to x2. Throughout block 4, x refers to x4. Therefore, this is legal. Same with i and objX -- they are used in blocks 3 and 5 and mean different things in each. But nowhere is the same simple name used to mean two different things throughout the same block.
Now, you might note that considering all of block 1, x is used to mean both x2 and x4. But there's no mention of x that is inside block 1 but NOT also inside another block. Therefore we don't count the inconsistent usage in block 1 as relevant.
Also, none of the declaration spaces overlap in illegal ways.
Therefore, this is legal.

From the C# Language Specification...
The scope of a local variable declared
in a local-variable-declaration is the
block in which the declaration occurs.
It is an error to refer to a local
variable in a textual position that
precedes the local-variable-declarator
of the local variable. Within the
scope of a local variable, it is a
compile-time error to declare another
local variable or constant with the
same name.
In code sample 1, both i and objX are declared in the scope of the function, so no other variable in any block inside that function can share a name with them. In code sample 2, both objXs are declared inside of the for loops, meaning that they do not violate the rule of not redeclaring local variables in inner scopes from another declaration.

You are allowed to use the same variable name in non-overlapping scopes. If one scope overlaps another, though, you cannot have the same variable declared in both. The reason for that is to prevent you from accidentally using an already-used variable name in an inner scope, like you did with i in the first example. It's not really to prevent the objX error since that would, admittedly, not be very confusing, but the error's a consequence of how the rule is applied. The compiler treats objX as having provenance throughout the scope in which it is declared both before and after its declaration, not just after.
In the second example the two for loops have independent, non-overlapping scopes, so you are free to re-use i and objX in the second loop. It's also the reason you can re-use x as your loop counter. Obviously, it would be a dumb restriction if you had to make up different names for each for(i=1;i<10;++i) style loop in a function.
On a personal note, I find this error annoying and prefer the C/C++ way of allowing you do to whatever you want, confusion be damned.

you should not be getting a compilation error with the second sample. Try renaming the variables to different letters/names and recompile again as it may be so other issue with the code most likely you've missed a curly bracket and changed the variables scope range.

Why is the scope of if and delegates this way in c#

Inspired by this question I began wondering why the following examples are all illegal in c#:
VoidFunction t = delegate { int i = 0; };
int i = 1;
and
{
int i = 0;
}
int i = 1;
I'm just wondering if anyone knew the exact reason why the language was designed this way? Is it to discourage bad programming practice, and if so why not just issue a warning?, for performance reasons (compiling and when running) or what is the reason?

This behavior is covered in section 3 of the C# language specification. Here is the quote from the spec
Similarly, any expression that
occurs as the body of an anonymous
function in the form of a
lambda-expression creates a
declaration space which contains the
parameters of the anonymous function.
It is an error for two members of a
local variable declaration space to
have the same name. It is an error for
the local variable declaration space
of a block and a nested local variable
declaration space to contain elements
with the same name. Thus, within a
nested declaration space it is not
possible to declare a local variable
or constant with the same name as a
local variable or constant in an
enclosing declaration space.
I think the easier way to read this is that for the purpose of variable declaration (and many other block related functions) a lambda/anonymous delegate block are treated no different than a normal block.
As to why the the language was designed this way the spec does not explicitly state. My opinion though is simplicity. If the code is treated as just another block then it makes code analysis routines easier. You can preserve all of your existing routines to analyze the block for semantical errors and name resolution. This is particularly important when you consider variable lifting. Lambdas will eventually be a different function but they still have access to all in scope variables at the declaration point.

I think it is done this way so that the inner scope can access variables declared in the outer scope. If you were allowed to over-write variables existing in the outer scope, there may be confusion about what behavior was intended. So they may have decided to resolve the issue by preventing it from happening.

I think it's this way to prevent devs from shooting themselves in the foot.