Foreach Loop – Foreach Loop and Variable Initialization

TL;DR - they're equivalent examples at the IL layer.

DotNetFiddle makes this pretty to answer as it allows you to see the resulting IL.

I used a slightly different variation of your loop construct in order to make my testing quicker. I used:

Variation 1:

using System;
                    
public class Program
{
    public static void Main()
    {
        Console.WriteLine("Hello World");
        int x;
        int i;
        
        for(x=0; x<=2; x++)
        {
            i = x;
            Console.WriteLine(i);
        }
    }
}

Variation 2:

        Console.WriteLine("Hello World");
        int x;
        
        for(x=0; x<=2; x++)
        {
            int i = x;
            Console.WriteLine(i);
        }

In both cases, the compiled IL output rendered the same.

.class public auto ansi beforefieldinit Program
       extends [mscorlib]System.Object
{
  .method public hidebysig static void  Main() cil managed
  {
    // 
    .maxstack  2
    .locals init (int32 V_0,
             int32 V_1,
             bool V_2)
    IL_0000:  nop
    IL_0001:  ldstr      "Hello World"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  ldc.i4.0
    IL_000d:  stloc.0
    IL_000e:  br.s       IL_001f

    IL_0010:  nop
    IL_0011:  ldloc.0
    IL_0012:  stloc.1
    IL_0013:  ldloc.1
    IL_0014:  call       void [mscorlib]System.Console::WriteLine(int32)
    IL_0019:  nop
    IL_001a:  nop
    IL_001b:  ldloc.0
    IL_001c:  ldc.i4.1
    IL_001d:  add
    IL_001e:  stloc.0
    IL_001f:  ldloc.0
    IL_0020:  ldc.i4.2
    IL_0021:  cgt
    IL_0023:  ldc.i4.0
    IL_0024:  ceq
    IL_0026:  stloc.2
    IL_0027:  ldloc.2
    IL_0028:  brtrue.s   IL_0010

    IL_002a:  ret
  } // end of method Program::Main

So to answer your question: the compiler optimizes out the declaration of the variable, and renders the two variations equivalent.

To my understanding, the .NET IL compiler moves all variable declarations to the beginning of the function but I couldn't find a good source that clearly stated that². In this particular example, you see that it moved them up with this statement:

    .locals init (int32 V_0,
             int32 V_1,
             bool V_2)

Wherein we get a bit too obsessive in making comparisons....

Case A, do all variables get moved up?

To dig into this a bit further, I tested the following function:

public static void Main()
{
    Console.WriteLine("Hello World");
    int x=5;
    
    if (x % 2==0) 
    { 
        int i = x; 
        Console.WriteLine(i); 
    }
    else 
    { 
        string j = x.ToString(); 
        Console.WriteLine(j); 
    } 
}

The difference here is that we declare either an int i or a string j based upon the comparison. Again, the compiler moves all the local variables to the top of the function² with:

.locals init (int32 V_0,
         int32 V_1,
         string V_2,
         bool V_3)

I found it interesting to note that even though int i won't be declared in this example, the code to support it is still generated.

Case B: What about foreach instead of for?

It was pointed out that foreach has different behavior than for and that I wasn't checking the same thing that had been asked about. So I put in these two sections of code to compare the resulting IL.

int declaration outside of the loop:

    Console.WriteLine("Hello World");
    List<int> things = new List<int>(){1, 2, 3, 4, 5};
    int i;

    foreach(var thing in things)
    {
        i = thing;
        Console.WriteLine(i);
    }

int declaration inside of the loop:

    Console.WriteLine("Hello World");
    List<int> things = new List<int>(){1, 2, 3, 4, 5};

    foreach(var thing in things)
    {
        int i = thing;
        Console.WriteLine(i);
    }

The resulting IL with the foreach loop was indeed different from the IL generated using the for loop. Specifically, the init block and the loop section changed.

.locals init (class [mscorlib]System.Collections.Generic.List`1<int32> V_0,
         int32 V_1,
         int32 V_2,
         class [mscorlib]System.Collections.Generic.List`1<int32> V_3,
         valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<int32> V_4,
         bool V_5)
...
.try
{
  IL_0045:  br.s       IL_005a

  IL_0047:  ldloca.s   V_4
  IL_0049:  call       instance !0 valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<int32>::get_Current()
  IL_004e:  stloc.1
  IL_004f:  nop
  IL_0050:  ldloc.1
  IL_0051:  stloc.2
  IL_0052:  ldloc.2
  IL_0053:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_0058:  nop
  IL_0059:  nop
  IL_005a:  ldloca.s   V_4
  IL_005c:  call       instance bool valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<int32>::MoveNext()
  IL_0061:  stloc.s    V_5
  IL_0063:  ldloc.s    V_5
  IL_0065:  brtrue.s   IL_0047

  IL_0067:  leave.s    IL_0078

}  // end .try
finally
{
  IL_0069:  ldloca.s   V_4
  IL_006b:  constrained. valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<int32>
  IL_0071:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
  IL_0076:  nop
  IL_0077:  endfinally
}  // end handler

The foreach approach generated more local variables and required some additional branching. Essentially, on the first time in it jumps to the end of the loop to get the first iteration of the enumeration and then jumps back to almost the top of the loop to execute the loop code. It then continues to loop through as you'd expect.

But beyond the branching differences caused by using the for and foreach constructs, there was no difference in the IL based upon where the int i declaration was placed. So we're still at the two approaches being equivalent.

Case C: What about different compiler versions?

In a comment that was left¹, there was a link to an SO question regarding a warning about variable access with foreach and using closure. The part that really caught my eye in that question was that there may have been differences in how the .NET 4.5 compiler worked versus earlier versions of the compiler.

And that's where the DotNetFiddler site let me down - all they had available was .NET 4.5 and a version of the Roslyn compiler. So I brought up a local instance of Visual Studio and started testing out the code. To make sure I was comparing the same things, I compared locally built code at .NET 4.5 to the DotNetFiddler code.

The only difference that I noted was with the local init block and variable declaration. The local compiler was a bit more specific in naming the variables.

  .locals init ([0] class [mscorlib]System.Collections.Generic.List`1<int32> things,
           [1] int32 thing,
           [2] int32 i,
           [3] class [mscorlib]System.Collections.Generic.List`1<int32> '<>g__initLocal0',
           [4] valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<int32> CS$5$0000,
           [5] bool CS$4$0001)

But with that minor difference, it was so far, so good. I had equivalent IL output between the DotNetFiddler compiler and what my local VS instance was producing.

So I then rebuilt the project targeting .NET 4, .NET 3.5, and for good measure .NET 3.5 Release mode.

And in all three of those additional cases, the generated IL was equivalent. The targeted .NET version had no effect on the IL that was generated in these samples.

To summarize this adventure: I think we can confidently say that the compiler does not care where you declare the primitive type and that there is no effect upon memory or performance with either declaration method. And that holds true regardless of using a for or foreach loop.

I considered running yet another case that incorporated a closure inside of the foreach loop. But you had asked about the effects of where a primitive type variable was declared, so I figured I was delving too far beyond what you were interested in asking about. The SO question I mentioned earlier has a great answer that provides a good overview about closure effects on foreach iteration variables.

¹ _{Thank you to Andy for providing the original link to the SO question addressing closures within foreach loops.}

² _{It's worth noting that the ECMA-335 spec addresses this with section I.12.3.2.2 'Local variables and arguments'. I had to see the resulting IL and then read the section for it to be clear regarding what was going on. Thanks to ratchet freak for pointing that out in chat.}