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:
…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
Evaluateas: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
Evaluateit happens on the lineint i = 10;. With this knowledge of the actual lifetime of the function’s locali, the compiler is correct: the use ofithere will conflict with the earlier use ofiin the lambda.You can use explicit scoping to avoid this:
In the case of
Evaluate3you simply note that whilst both lambdas share the parent function scope, they also have their own, and it’s in there that theiris are declared – and that’s why they don’t interfere with each other (they are, in effect, sibling scopes).Incidentally
EvaluateandEvaluate3can ultimately be simplified to this: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
iactually has a different type in each. Like I say – I’ve never done it again and the code in question is no longer live 🙂