What is the scope of local variable declared in Linq Query.
I was writing following code
static void Evaluate()
{
var listNumbers = Enumerable.Range(1, 10).Select(i => i);
int i = 10;
}
Compiler flagged error on line int i=10, stating
A local variable named 'i' cannot be declared in this scope because it would give a different meaning to 'i', which is already used in a 'child' scope to denote something else
I am unable to understand why this error is coming.
My understanding was that i will become out of scope after first line (in foreach loop). So i can be declared again.
Actual behavior is that i cannot be accessed after first line (in foreach loop), which is correct. But i cannot be declared again. This seems strange.
EDIT
This is a following question based on response by Andras. The answer is very good, but causes further doubts.
static void Evaluate3()
{
var listNumbers = Enumerable.Range(1, 10).Select(i => i);
var listNumbers1 = Enumerable.Range(1, 10).Select(i => i);
}
Based on the logic of function Evaluate that .Select(i=>i), and int i=10, both i, are local to function block and hence complication error.
Function Evaluate3 should not compile as well as there are two i in the method block, but it is compiling successfully without any warning/error.
Question, Either both Evaluate and Evaluate3 should not compile, or both should compile.
The key fact to note here is that a declaration:
int i;
...takes effect across the whole enclosing scope from start to finish - not just from the point at which it is declared. In .Net the declaration of a local variable is just an instruction to the compiler to reserve that name and local for the entire scope. That means once it's declared, it's already reserved for all lines before and after.
In effect, it means that you should actually read Evaluate as:
static void Evaluate()
{
int i;
var listNumbers = Enumerable.Range(1, 10).Select(i => i);
i = 10;
}
And if you do write your method accordingly, you'll see that the the compiler error occurs on the lambda declaration instead - which is perfectly reasonable. Thankfully, the C# compiler is clever enough, from a human perspective, to recognise that ordering of code is important to us, and it actually assigns the compiler error to whichever source line is the second or subsequent declaration; hence why in your version of Evaluate it happens on the line int i = 10;. With this knowledge of the actual lifetime of the function's local i, the compiler is correct: the use of i there will conflict with the earlier use of i in the lambda.
You can use explicit scoping to avoid this:
static void Evaluate()
{
var listNumbers = Enumerable.Range(1, 10).Select(i => i);
{
int i = 10;
}
}
In the case of Evaluate3 you simply note that whilst both lambdas share the parent function scope, they also have their own, and it's in there that their is are declared - and that's why they don't interfere with each other (they are, in effect, sibling scopes).
Incidentally Evaluate and Evaluate3 can ultimately be simplified to this:
static void Evaluate()
{
{
int i;
}
int i; //<-- error
}
static void Evaluate3()
{
{
int i;
}
{
int i;
}
//fine here - both i's are in different scopes.
}
And it's actually the second scenario here that I've used explicit scoping for before - that is, in different scopes within the same function, where the i actually has a different type in each. Like I say - I've never done it again and the code in question is no longer live :)
From the spec:
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.
Your lambda i => i is inside the scope of the local variable int i = 10 even though it is declared beforehand. Rather than throwing an error because you're using i before it is declared, the compiler is helpfully pointing out that you've already used i to refer to something else and that this declaration would change that.
EDIT: Following your update:
In the first case, your first i is enclosed within the lambda, but your second i encompasses the whole Evaluate method including the lambda - hence you get the error.
In the second case, your first i is enclosed within its lambda, and your second i is enclosed within its lambda - neither i is within the scope of the other, so there is no error.
Your paragraph "Based on the logic of ... both i, are local to function block..." is incorrect - the first i is not local to the function block but to the lambda.
