It's really only a breaking change if you designed your program to have the closure from inside the loop purposely use the last element of the collection outside the loop. Who would do this? I've hit this issue lots of times as have others, and it's a bug that is fixed by copying the iterator inside the loop. It's nice I won't need to worry about that anymore.
Yep, that's why it's a breaking change (or why breaking changes are bad). On the other hand, if they're using the C# 5 compiler to output C# 4 projects then maybe there will be a new warning (which, of course, is another breaking change if you treat warnings as errors).
Comments
It's really only a breaking change if you designed your program to have the closure from inside the loop purposely use the last element of the collection outside the loop. Who would do this? I've hit this issue lots of times as have others, and it's a bug that is fixed by copying the iterator inside the loop. It's nice I won't need to worry about that anymore.
Exactly. Their rational was that there won't be that many people using the weird existing behavior:
More discussion on Eric's blog on this topic:
http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi...
http://blogs.msdn.com/b/ericlippert/archive/2009/11/16/closi...
The bigger issue will be the confusion when people who are used to the C# 5 semantics work on a C# 4 project.
Yep, that's why it's a breaking change (or why breaking changes are bad). On the other hand, if they're using the C# 5 compiler to output C# 4 projects then maybe there will be a new warning (which, of course, is another breaking change if you treat warnings as errors).
Agreed. I inherited some code for a live app at work and this exact issue was causing a bug.