I modified your code so they're actually equivalent of each other:
class Program
{
static void Main(string[] args)
{
IEnumerable<string> enumerable = new List<string> { "a", "b", "c" };
foreach (string element in enumerable)
{
object item = element;
item = "d";
}
IEnumerator enumerator = enumerable.GetEnumerator();
while (enumerator.MoveNext())
{
object item = enumerator.Current;
item = "d";
}
}
}
As you can see, in neither form do we assign to the readonly enumerator.Current
When you write a foreach, the compiler rewrites your code for you, so that it looks like this:
IEnumerable<string> enumerable = new List<string> { "a", "b", "c" };
//you write
foreach (string element in enumerable)
{
Console.WriteLine(element);
}
//the compiler writes
string element;
var enumerator = enumerable.GetEnumerator();
try
{
while (enumerator.MoveNext())
{
element = enumerator.Current;
//begin your foreach body code
Console.Write(element);
//end your foreach body code
}
}
finally
{
enumerator.Dispose();
}
With each passing version, C# evolves in a couple of ways. New processing structures can certainly be added to the language, but often "syntactic sugar" is an evolution achieved by having the compiler able to translate the code you write into a feature that already exists, such as foreach(x in y) becoming y.GetEnumerator(); while(..){ x = enumerator.Current; ... }.
Similarly, string interpolation $"There are {list.Count:N2} items" being transformable to the implemented-firststring.Format("There are {0:N2} items, list.Count")`.
Indeed, if one considers the job of the compiler to transform something that is written into something else that is already written, then even syntactic sugaring is an example of a new processing structure, because everything is already written (right the way down to the hardware)
To examine how the compiler rewrites a foreach, I wrote two methods:
static void ForEachWay(){
var enumerable = new List<string>();
enumerable.Add("a");
enumerable.Add("b");
enumerable.Add("c");
//you write
foreach (string element in enumerable)
{
Console.WriteLine(element);
}
}
static void EnumWayWithLoopVar(){
var enumerable = new List<string>();
enumerable.Add("a");
enumerable.Add("b");
enumerable.Add("c");
string e;
var enumerator = enumerable.GetEnumerator();
try{
while (enumerator.MoveNext())
{
e = enumerator.Current;
Console.Write(e);
}
}finally{
enumerator.Dispose();
}
}
I compiled with csc.exe that came with .NET SDK 4.7.2, then used ILDASM to visualize the generated MSIL (screenshot to show the side by side diff). The initial part of the method, setup, variables declare etc are identical but for a no-op:
As are the loop bodies:
The only difference discernible is in the disposing; I wasn't too interested in chasing down the reasons why.
So, it's clear that the compiler rewrites the method in the way shown. Your original question can only really be answered by the person that wrote the compiler, but it seems logical to me that it's an extension of the prohibition against assigning to enumerator.Current - it wouldn't make sense to prevent that but allow you to assign to the variable equivalent of it declared in your foreach loop. It's also clear that it's a special case assessed directly, from the way the error message talks abut the foreach loop specifically.
I'd also say (opinion part) that preventing assignment to the foreach loop iterator variable prevents harm/unintended consequences/obscure bugs, with no drawback that I can discern. If you want a variable you can reassign; make another one
