Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C#

IEnumerable: Lazy and Dangerous

3.88/5 (16 votes)
12 Jul 2014Apache2 min read 50.2K  
IEnumerable: Lazy and Dangerous

Time and time again, I am burnt by the same bug in my code.

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.

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.

For example,

C#
IEnumerable<string> names = new[] { "Paris", "Berlin", "London" }; // enumerator
IEnumerable<City> cities = names.Select(name=>new City(name)); // generator

Every time you do foreach (var city in cities), a different set of cities is produced. E.g.

C#
foreach (var city in cities) city.Visited = true;
...
foreach (var city in cities)
{
    Console.WriteLine(city.Visited); // prints false
}

One can easily convert a generator to an enumerator by adding ToList(), ToArray(), or ToDictionary(). This will create a “real” data structure that is not modified.

C#
var cityList = names.Select(name=>new City(name)).ToList();
foreach (var city in cityList) city.Visited = true;
...
foreach (var city in cityList)
{
    Console.WriteLine(city.Visited); // prints true
}

Even more subtle issues can occur when using conditions:

C#
cityList[0].Visited = true;
var visitedCities = cityList.Where(city=>city.Visited);
Console.WriteLine( visitedCities.Count() ); // 1
...
cityList[0].Visited = false;
Console.WriteLine( visitedCities.Count() ); // 0

This is an obvious case of hidden dependency. We modified something inside cityList, but it “magically” affects similarly unrelated visitedCities. Hidden dependencies are evil, because they are, well, hidden, and people tend to forget about them.

The 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 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.

It does not mean one should not use IEnumerable in stateful scenarios, but it is better to be careful, you have been warned!

PS From the Future (2014). Resharper has a warning for multiple enumerations of an IEnumerable. If you pay attention to the warning, your chances of been burnt by this bug will be greatly reduced. Unfortunately, Resharper costs money, and to the best of my knowledge out-of-the-box versions of Visual Studio/C# compiler do not have such warning.

License

This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0