The System.Lazy<T> type in the new .NET 4.0 framework came to my attention recently. This type is not at all revolutionary. In fact, everyone could have written it themselves in under 10 lines of code going as far back as the .NET 2.0 framework.

Some less experienced programmers won’t realize however, that deferring the call to a delegate could have nasty side effects.

Consider the following code snippet:

static void Main(string[] args)
{
    List<Lazy<string>> lazyInit = new List<Lazy<string>>();
    for (char letter = 'A'; letter <= 'Z'; letter++)
    {
        var lazy = new Lazy<string>(() => letter.ToString());
        lazyInit.Add(lazy);
    }
    foreach (var lazy in lazyInit)
    {
        Console.Write(lazy.Value);
    }
    Console.ReadLine();
}

The code is pretty straight forward, but what gets printed here? Would you think it’s the alphabet? You would be very wrong.

The output is exactly ‘ZZZZZZZZZZZZZZZZZZZZZZZZZ’. Go ahead, run it yourself if you don’t trust me.

To understand why this happens, you need to understand how closures work.

In the constructor to the Lazy<> class, you’re passing in a delegate, in the form of a lambda. This delegate captures the letter variable (attention, not its value at the time of the call, but the variable as a whole) and creates a closure class around it behind the scenes. This may be counter-intuitive to the average programmer.  For further information on what happens behind the scenes with captured variables and closures, read this great post by Marc Gravell.

This is not specific behavior of the new Lazy<T> class, it’s what happens every time a delegate is stored for deferred execution.

If you rewrite the code without deferred execution, you’ll see that the problem doesn’t manifest itself:

static void Main(string[] args)
{
    for (char letter = 'A'; letter <= 'Z'; letter++)
    {
        var lazy = new Lazy<string>(() => letter.ToString());
        Console.Write(lazy.Value);
    }
    Console.ReadLine();
}
// Output: ABCDEFGHIJKLMNOPQRSTUVWXYZ

Same delegate is being used, but it is executed immediately. The output is now the complete English alphabet, as you would expect.

This isn’t very useful however, We’ve completely thrown away the advantages of the Lazy<T> class and we might as well not be using it.

So, how can we fix it? We need to use an intermediary variable inside the body of the for loop that is simply a copy of the outer variable. The inner variable’s scope is unique to each loop iteration, so it matters a whole lot where you define your variables.

Fixed code:

static void Main(string[] args)
{
    List<Lazy<string>> lazyInit = new List<Lazy<string>>();

    // char letter2; // <- for the sake of exercise, uncomment this line and remove the ‘char’ keyword from the initialization of the letter2 variable inside the for loop below. the ‘bug’ will manifest itself again
    for (char letter = 'A'; letter <= 'Z'; letter++)
    {
        char letter2 = letter; // value re-captured in inner block (remove ‘char’ keyword and uncomment line above to see the ‘bug’ manifest itself again)
        var lazy = new Lazy<string>(() => letter2.ToString());
        lazyInit.Add(lazy);
    }
    foreach (var lazy in lazyInit)
    {
        Console.Write(lazy.Value);
    }
    Console.ReadLine();
}

One tool that can automatically check for this condition so you can avoid headaches later is JetBrain’s Resharper. With Resharper installed, you’d see a warning underneath () => letter.ToString() which spells ‘Access to modified closure’ and suggests the same fix I described in this blog post.

If anyone’s interested in seeing how the same Lazy<T> class could be implemented in .NET 2.0 and up, leave a comment and I’ll post it here!