I was reading an article about Whidbey, which I'll be posting about shortly, and I thought about how stupid it is to have both the for and foreach loop structures (I also noticed this post when I logged on to write this). Don't get me wrong, I understand that it's easier to use the foreach loop, but considering the performance issues, why would you? I see VB developers doing it all the time and I just shake my head in partial disgust (maybe that's a tad strong).
Anyway, my issue with this fault is not necessarily with developers, but with Microsoft. Let's think about it. A for loop...
for ( int i=0; i < colComplaints; i++ )
{
colComplaints[i].Whine();
...
}
... and its equivalent foreach loop ...
foreach ( Complaint cmpTemp in colComplaints )
{
cmpTemp.Whine();
...
}
... are very similar. The changes are negligible, but you have to admit that the latter is slightly more readable. And, considering how similar these two approaches are, I imagine the IL can't be too far off (perhaps I will investigate that). Microsoft (sh)could optimize this code at compile-time. Think about it: How hard would it be to convert the for header and replace any instance of the temporary variable with the actual collection/object iterator reference? You can't use the foreach unless an iterator has been identified; and, I'd like to hope that finding the iterator and converting foreach IL code to for loop IL code should be pretty easy, considering some of the advanced things .NET takes on.
This is just an outsider looking in, of course, but hopefully someone at Microsoft will see this possibility and push some sort of change in a future release of their compilers. Considering the [assumed] ease of the compiler modification and the level of freedom it would provide developers (albeit for a simple task), I would have to say that its worth it. Honestly, the only reason I don't use foreach is because of performance.