Lambda capture problem with iterators?

Question

Apologies if this question has been asked already, but suppose we have this code (I've run it with Mono 2.10.2 and compiled with gmcs 2.10.2.0):

using System;

public class App {
    public static void Main(string[] args) {
        Func<string> f = null;
        var strs = new string[]{
            "foo",
            "bar",
            "zar"
        };

        foreach (var str in strs) {
            if ("foo".Equals(str)) 
                f = () => str;
        }
        Console.WriteLine(f());     // [1]: Prints 'zar'

        foreach (var str in strs) {
            var localStr = str;
            if ("foo".Equals(str))
                f = () => localStr;
        }
        Console.WriteLine(f());     // [2]: Prints 'foo'

        { int i = 0;
        for (string str; i < strs.Length; ++i) {
            str = strs[i];
            if ("foo".Equals(str)) 
                f = () => str;
        }}
        Console.WriteLine(f());     // [3]: Prints 'zar'
    }
}

It seems logical that [1] print the same as [3]. But to be honest, I somehow expected it to print the same as [2]. I somehow believed the implementation of [1] would be closer to [2].

Question: Could anyone please provide a reference to the specification where it tells exactly how the str variable (or perhaps even the iterator) is captured by the lambda in [1].

I guess what I am looking for is the exact implementation of the foreach loop.

Answer 1

You asked for a reference to the specification; the relevant location is section 8.8.4, which states that a "foreach" loop is equivalent to:

    V v;
    while (e.MoveNext()) {
        v = (V)(T)e.Current;
        embedded-statement
    }

Note that the value v is declared outside the while loop, and therefore there is a single loop variable. That is then closed over by the lambda.

UPDATE

Because so many people run into this problem the C# design and compiler team changed C# 5 to have these semantics:

    while (e.MoveNext()) {
        V v = (V)(T)e.Current;
        embedded-statement
    }

Which then has the expected behaviour -- you close over a different variable every time. Technically that is a breaking change, but the number of people who depend on the weird behaviour you are experiencing is hopefully very small.

Be aware that C# 2, 3, and 4 are now incompatible with C# 5 in this regard. Also note that the change only applies to foreach, not to for loops.

See http://ericlippert.com/2009/11/12/closing-over-the-loop-variable-considered-harmful-part-one/ for details.

---

Commenter abergmeier states:

C# is the only language that has this strange behavior.

This statement is categorically false. Consider the following JavaScript:

var funcs = [];
var results = [];
for(prop in { a : 10, b : 20 })
{
  funcs.push(function() { return prop; });
  results.push(funcs[0]());
}

abergmeier, would you care to take a guess as to what are the contents of results?

Answer 2

The core difference between 1 / 3 and 2 is the lifetime of the variable which is being captured. In 1 and 3 the lambda is capturing the iteration variable str. In both for and foreach loops there is one iteration variable for the lifetime of the loop. When the lambda is executed at the end of the loop it executes with the final value: zar

In 2 you are capturing a local variable who's lifetime is a single iteration of the loop. Hence you capture the value at that time which is "foo"

The best reference I can you you to is Eric's blog post on the subject

• http://ericlippert.com/2009/11/12/closing-over-the-loop-variable-considered-harmful-part-one/

Answer 3

For the people from google

I've fixed lambda bug using this approach:

I have changed this

for(int i=0;i<9;i++)
    btn.OnTap += () => { ChangeCurField(i * 2); };

to this

for(int i=0;i<9;i++)
{
    int numb = i * 2;
    btn.OnTap += () => { ChangeCurField(numb); };
}

This forces "numb" variable to be the only one for the lambda and also makes generate at this moment and not when lambda is called/generated < not sure when it happens.

Answer 4

The following happens in loop 1 and 3:

The current value is assigned to the variable str. It is always the same variable, just with a different value in each iteration. This variable is captured by the lambda. As the lambda is executed after the loop finishes, it has the value of the last element in your array.

The following happens in loop 2:

The current value is assigned to a new variable localStr. It is always a new variable that gets the value assigned. This new variable is captured by the lambda. Because the next iteration of the loop creates a new variable, the value of the captured variable is not changed and because of that it outputs "foo".