Time and time again I am burnt by the same bug.<\/p>\n
There are two kinds of enumerables in .NET: enumerators and generators. Enumerators go over some collection and return its items. Enumerator will always return the same values, no matter how many times you iterate over it. This only changes when someone adds or removes items from the collection.<\/p>\n
Generators, on the other hand, compute new values every time. They may or may not be the same, depending on how the generator is built and what happened around it. All those neat LINQ methods like “where” and “select” are in fact generators.<\/p>\n
For example,<\/p>\n
IEnumerable<string> names = new[] { \"Paris\", \"Berlin\", \"London\" }; \/\/ enumerator\nIEnumerable<City> cities = names.Select(name=>new City(name)); \/\/ generator<\/code><\/pre>\nEvery time time you do foreach (var city in cities)<\/code> a different set of cities is produced. E.g.<\/p>\nforeach (var city in cities) city.Visited = true;\n...\nforeach (var citiy in cities)\n{\n Console.WriteLine(city.Visited); \/\/ prints false\n}<\/code><\/pre>\nOne can easily convert a generator to an enumerator by adding ToList()<\/code>, ToArray()<\/code>, or ToDictionary()<\/code>. This will create a “real” data structure that is not modified.<\/p>\nvar cityList = names.Select(name=>new City(name)).ToList();<\/b><\/font>\nforeach (var city in cityList) city.Visited = true;\n...\nforeach (var citiy in cityList)\n{\n Console.WriteLine(city.Visited); \/\/ prints true\n}<\/code><\/pre>\nEven more subtle issues can occur when using conditions:<\/p>\n
<\/p>\ncityList[0].Visited = true;\nvar visitedCities = cityList.Where(city=>city.Visited);\nConsole.WriteLine( visitedCities.Count() ); \/\/ 1\n...\ncityList[0].Visited = false;\nConsole.WriteLine( visitedCities.Count() ); \/\/ 0<\/pre>\n<\/code><\/p>\n
This is an obvious case of hidden dependency. We modified something inside cityList, but it “magically” affects similarly unrelated visitedCities<\/code>. Hidden dependencies are evil, because they are, well, hidden, and people tend to forget about them.<\/p>\nThe most annoying part is that generators and enumerators look exactly the same, and it may be quite difficult, or even impossible to tell whether particular IEnumerable<\/code> is a generator or an enumerator. Functional style programming assumes read-only objects, so it does not matter, but throwing in any modifiable state creates a dangerous mix.<\/p>\nIt does not mean one should not use IEnumerable<\/code> in stateful scenarios, but it is better to be careful, you have been warned!