Scope and Lifetime

Scope is where a name can be used. Lifetime is how long the value behind it exists. Most of the time they match, and the interesting cases are the ones where they do not.

Both are decided by braces. A pair of braces makes a block, and a variable declared inside it belongs to it.

decimal subtotal = 100m;

if (subtotal > 50m)
{
    decimal discount = subtotal * 0.05m;   // exists only inside these braces
    subtotal -= discount;
}

// Console.WriteLine(discount);   // build error: not in scope out here

for (int i = 0; i < 3; i++)
{
    Console.WriteLine($"Pass {i}");
}

// Console.WriteLine(i);          // build error: i belonged to the loop

Console.WriteLine(subtotal);      // 95 — declared outside, so still available

• A variable exists from its declaration to the closing brace of its block, and nowhere else.
• A for loop's counter belongs to the loop. Needing it afterwards means declaring it before the loop starts.
• An inner block can see the variables of the block around it. The reverse is never true, which is why discount cannot be read below.
• C# also refuses to let an inner block declare a name that is already in scope. Other languages allow that shadowing, and it produces bugs where a reader believes they are looking at the outer variable.

var item = new StockItem(10);

item.Receive(5);
Console.WriteLine(item.Quantity);   // 10 — the delivery was lost

public class StockItem
{
    private int quantity;

    public StockItem(int quantity)
    {
        this.quantity = quantity;   // this. means the field; the bare name means the parameter
    }

    public int Quantity => quantity;

    public void Receive(int delivered)
    {
        int quantity = this.quantity + delivered;   // a new local that hides the field
        Console.WriteLine($"Now holding {quantity}");
    }
}

• In the constructor, the parameter and the field have the same name, so the plain name refers to the parameter. this.quantity says you mean the field.
• In Receive, the local hides the field for the rest of the method. The code compiles, prints a believable number, and the field is never updated.
• Nothing here is an error, which is what makes it worth knowing. The compiler cannot tell that you meant the field.
• Two habits avoid it: name locals differently from fields, and keep the constructor as the only place where the two names meet.

List<Action> fromFor = new List<Action>();

for (int i = 0; i < 3; i++)
{
    fromFor.Add(() => Console.Write(i));   // all three capture the same i
}

foreach (Action print in fromFor)
{
    print();      // 333
}

Console.WriteLine();

List<Action> fromForeach = new List<Action>();

foreach (int value in new[] { 0, 1, 2 })
{
    fromForeach.Add(() => Console.Write(value));   // a fresh value each pass
}

foreach (Action print in fromForeach)
{
    print();      // 012
}

Console.WriteLine();

• A for loop has one counter for all its passes. All three lambdas captured that one variable, and by the time they run it holds 3.
• A foreach declares a new variable on each pass, so each lambda captured a different one. C# changed this in version 5 precisely because the old shared behaviour surprised everybody.
• To fix the for version, copy the counter into a variable declared inside the body and capture that instead.
• This is also proof that a captured local outlives its block: the lambdas ran after the loop finished, and the values were still there.