_TL;DR_ - they're equivalent examples at the IL layer.
---
[DotNetFiddle](https://dotnetfiddle.net/) 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<sup>2</sup>. 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<sup>2</sup> 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](https://softwareengineering.stackexchange.com/questions/296803/foreach-loop-and-variable-initialization/296812#comment615312_296812)<sup>1</sup>, there was a link to an [SO question regarding a warning about variable access with foreach and using closure](http://stackoverflow.com/q/14907987/1345223). 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](http://stackoverflow.com/a/14917351/1345223) that provides a good overview about closure effects on foreach iteration variables.
<sup>1</sup> <sub>_Thank you to Andy for providing the original link to the SO question addressing closures within `foreach` loops._</sub>
<sup>2</sup> <sub>_It's worth noting that [the ECMA-335 spec](http://www.ecma-international.org/publications/standards/Ecma-335.htm) 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._</sub>