Is there a reason for C#'s reuse of the variable in a foreach?

In older versions of C#, the foreach loop reuses the iteration variable. That is, underneath the hood, the compiler creates a single iteration variable and reassigns it on every pass of the loop. This design choice originally simplified the compiler’s job and was considered an acceptable approach. However, it led to surprising behavior when closures (e.g., lambda expressions or anonymous methods) captured the loop variable, causing them all to reference the same modified variable.

// Pre-C# 5 behavior could surprise you:
var actions = new List<Action>();
int[] numbers = { 1, 2, 3 };

foreach (var number in numbers)
{
    // Each action closes over the *same* 'number' variable.
    actions.Add(() => Console.WriteLine(number));
}

// This would print "3" three times before C# 5 
// because the same variable was reused and updated.

What Changed and Why?

Starting with C# 5.0, the compiler was adjusted so that each iteration effectively uses a fresh copy of the iteration variable in scenarios where a closure captures it. This eliminates the “all lambdas see the final iteration value” problem.

Today, when you use a closure inside a foreach:

• The compiler generates separate variables for each iteration.
• Each lambda or anonymous method sees the value as it was in that specific iteration.

The main reason for the original design was compiler simplicity. Later, real-world usage and developer feedback showed it to be a common gotcha—especially when writing asynchronous code or capturing loop variables in lambdas. Microsoft addressed it in later language versions to align with developer expectations.

Practical Takeaways

1. Modern C#: If you’re using C# 5 or later (which is almost everyone at this point), closures in foreach loops will capture each iteration’s value individually—no need to do any trick like copying to a local variable inside the loop.
2. Backwards Compatibility: If you’re maintaining legacy code in older C# versions, be aware of this nuance and explicitly create a local copy if you need the old iterations’ values in your closures.
3. Readability: Although the compiler now does the right thing, it’s still good practice to keep your loop-based lambdas or delegates straightforward, possibly using named local variables if you’re doing anything complex.

Strengthen Your C# Fundamentals

Understanding nuances like the foreach variable reuse is part of writing bug-free, maintainable C#. If you’d like to level up your coding skills further—especially for technical interviews—consider these pattern-oriented courses from DesignGurus.io:

• Grokking the Coding Interview: Patterns for Coding Questions
• Grokking Data Structures & Algorithms for Coding Interviews

Additionally, the DesignGurus.io YouTube channel offers free tutorials on best practices for coding, system design, and common interview questions.