Update: fixed the title per comments and I noticed Rico chimed in.

I had two separate interactions today where someone told me they opted for ugly\error prone for-loop code because foreach was “too slow”.  There are so many things wrong with that analysis where do I start??

1. In one of the cases we were iterating over an array… Google helped me quickly find this post and Kevin is right, C# and VB make foreach of arrays just peachy. 
2. The rationale for why foreach is “too slow” was simply “Rico said so”.  Again a quick google search puts the direct facts to rest.  But the meta-issue, which I am sure Rico would agree with, is that there are very few “laws” of perf.  Know your scenarios and measures are the only two I think.  Because rico said didn’t work for me in 2^nd grade and it doesn’t work for you now either.
3. Yes, fine there is something to be aware of wrt foreach over ArrayList, which I will not repeat here but to say they very often are a wash in real world scenarios and developer productivity (on-time, less bugs) is almost always a better tradeoff.  In addition, you can mitigate this in your own collection types today and we have addressed it with List<T> in Whidbey.  
4. It is my belief most of our customers are not having significant perf issues on the platform (but I am always open to new data).  That is not to say the CLR doesn’t have some perf issue we need to address (we do!), I am just saying that on balance, for the kinds of apps customers are building today the value we give far outweighs the cost.  Where there are perf issues, I seriously doubt they are fixed by moving from foreach to for!
5. Eric tells me Java is adding foreach because it is such a useful feature… it can’t be that bad ;-)

Go, use foreach and be proud!