Introduction

The "access to foreach variable in closure" warning usually appears when a closure uses a loop variable in a way that can become ambiguous or misleading after the loop continues. The fix is normally to capture a stable value for the current iteration instead of relying on the reused loop variable directly.

Why the Warning Happens

In a foreach loop, the loop variable is reused on each iteration. When you create a closure inside that loop and later execute it, the closure may not behave the way you first expect if it closes over a changing variable.

Consider this pattern:

1<?php
2
3$callbacks = [];
4
5foreach ([1, 2, 3] as $number) {
6    $callbacks[] = function () use (&$number) {
7        echo $number . PHP_EOL;
8    };
9}
10
11foreach ($callbacks as $callback) {
12    $callback();
13}

That captures $number by reference. By the time the callbacks run, they are all tied to the same reused variable slot, which is why the result is surprising.

The Usual Fix: Capture by Value

In most cases, you want to capture the current iteration's value, not the variable by reference.

1<?php
2
3$callbacks = [];
4
5foreach ([1, 2, 3] as $number) {
6    $callbacks[] = function () use ($number) {
7        echo $number . PHP_EOL;
8    };
9}
10
11foreach ($callbacks as $callback) {
12    $callback();
13}

Now each closure gets its own copied value for that iteration.

An Explicit Intermediate Variable

Sometimes the warning appears even when the intent seems obvious. In that case, introducing an intermediate variable can make both the code and the analyzer happy:

1<?php
2
3$callbacks = [];
4
5foreach ([1, 2, 3] as $number) {
6    $currentNumber = $number;
7
8    $callbacks[] = function () use ($currentNumber) {
9        echo $currentNumber . PHP_EOL;
10    };
11}

This is a good pattern when the closure body is larger and you want the current loop value to be visually explicit.

Immediate Execution Is Different

If the closure is executed immediately inside the loop rather than stored for later, the problem is often smaller:

1<?php
2
3foreach ([1, 2, 3] as $number) {
4    $callback = function () use ($number) {
5        echo $number . PHP_EOL;
6    };
7
8    $callback();
9}

Even here, capturing by value is usually clearer. The warning is most important when closures are saved, returned, or queued for later execution.

References Make the Problem Worse

Things become even riskier if the loop itself uses references:

1<?php
2
3$items = [1, 2, 3];
4
5foreach ($items as &$item) {
6    // risky closure usage here
7}
8
9unset($item);

Reference-based foreach already has special gotchas in PHP. Adding closures that capture the same variable can make the behavior harder to reason about. If possible, avoid mixing reference iteration and closure capture unless there is a compelling reason.

A Realistic Example

Suppose you want to create a list of validation callbacks for form fields:

1<?php
2
3$fields = ['email', 'password', 'display_name'];
4$validators = [];
5
6foreach ($fields as $field) {
7    $validators[] = function (array $input) use ($field) {
8        return array_key_exists($field, $input) && $input[$field] !== '';
9    };
10}
11
12$input = ['email' => '[email protected]', 'password' => 'secret'];
13
14foreach ($validators as $validator) {
15    var_dump($validator($input));
16}

Capturing $field by value makes each validator stable and predictable.

Why Static Analysis Warns You

Many IDEs and static analyzers flag this pattern because it is easy to write code that looks correct but behaves incorrectly later. The warning is not saying closures inside loops are forbidden. It is warning that the loop variable itself is a moving target.

That is a helpful warning, not noise.

Common Pitfalls

The biggest pitfall is capturing the loop variable by reference with use (&$var) when you actually needed the current value of that iteration.

Another pitfall is assuming the closure runs immediately just because it is defined inside the loop. Stored callbacks, deferred jobs, and event handlers often execute much later.

A third pitfall is mixing foreach by reference and closure capture in the same block. That combination is more fragile than it first appears.

Finally, do not suppress the warning without understanding it. Usually the fix is simple and makes the code clearer anyway.

Summary

• The warning appears because the foreach loop variable is reused across iterations
• Closures should usually capture the current iteration value, not the variable by reference
• 'use ($value) is safer than use (&$value) in most loop-created closures'
• An intermediate variable can make the intent clearer and silence the warning cleanly
• The warning is useful because deferred closures often expose bugs that are hard to notice at first