Volker and I drafted a RFC:
https://wiki.php.net/rfc/scope-functions
Please consider it and share your feedback.
I hope it will alleviate pain around some of the most common forms of Closure usage which is "execute this now as part of the called function", which currently can require a lot of "use ($variables)".
For me the primary use case of use ($capturing) was always "I need this function later and want to explicitly document what escapes my function". This, however, required this straightforward usage of Closures to also document every single usage of a variable. Which is really not that beneficial at all.
Thus the scope functions as proposed will be able to fill that gap in future.
Thank you,
Bob
Le 6 mai 2026 à 22:09, Bob Weinand bobwei9@hotmail.com a écrit :
Volker and I drafted a RFC:
https://wiki.php.net/rfc/scope-functions
Please consider it and share your feedback.
I hope it will alleviate pain around some of the most common forms of Closure usage which is "execute this now as part of the called function", which currently can require a lot of "use ($variables)".
For me the primary use case of use ($capturing) was always "I need this function later and want to explicitly document what escapes my function". This, however, required this straightforward usage of Closures to also document every single usage of a variable. Which is really not that beneficial at all.
Thus the scope functions as proposed will be able to fill that gap in future.
Thank you,
Bob
Hi,
This is nice. As I understand it, this RFC could resolve problems that the Context Managers RFC tries to resolve in a simpler and more flexible way. (And it resolves other problems too, of course.)
Taking the first example from the Context Manager RFC:
using (file_for_write('file.txt') => $fp) {
foreach ($someThing as $value) {
fwrite($fp, serialize($value));
}
}
// implementable as:
function file_for_write(string $filename): ContextManager {
return new class($filename) implements ContextManager {
function __construct(private readonly string $filename) { }
private $fp;
function enterContext() {
$this->fp = @fopen($this->filename, 'w');
if (!$this->fp) {
throw new \RuntimeException('Couldn’t open file');
}
return $this->fp;
}
function exitContext(?\Throwable $e = null): ?\Throwable {
@fclose($this->fp);
return $e;
}
};
}
This can be rewritten as:
file_for_write('file.txt', fn($fp) {
foreach ($someThing as $value) {
fwrite($fp, serialize($value));
}
});
// implementable as (which is simpler: one function instead of a whole class):
function file_for_write (string $filename, callable $do_write): void {
$fp = @fopen($filename, 'w');
if (!$fp) {
throw new \RuntimeException('Couldn’t open file');
}
try {
$do_write($fp);
} finally {
@fclose($fp);
}
}
For those of us that abhor exceptions in case of recoverable failure, there is even more. With this RFC, one can easily return true/false (or whatever other signal) for success/failure, while Context Manager strongly leans towards the use of exceptions (although, of course, it remains possible to assign the outcome to a variable and to exit the context with break or goto):
$ok = file_for_write('file.txt', fn($fp) {
foreach ($someThing as $value) {
if (something_is_wrong_with($value))
return false;
fwrite($fp, serialize($value));
}
return true;
});
// implementable as (which is more flexible: exceptions are not the only type of signal):
#[\NoDiscard]
function file_for_write (string $filename, callable $do_write): bool {
$fp = @fopen($filename 'w');
if (!$fp) {
return false;
}
try {
return $do_write($fp);
} finally {
@fclose($fp);
}
}
—Claude
Volker and I drafted a RFC:
Hi Bob,
An I right in thinking that this is essentially equivalent to "automatic capture by closure", with an extra restriction on the lifetime of the resulting closure? It would be good to spell out in the RFC how this compares to other approaches, and other languages.
In particular, JavaScript's capture semantics are somewhat notorious as a source of confusion. A common example is creating closures in a loop which all use the same variable; as far as I can see, the proposed semantics would allow this as long as they were executed before the parent scope ends:
function parent_scope() {
$values = range(1,10);
$scoped_functions = [];
foreach( $values as $v ) {
$scoped_functions[] = fn($v) {
echo "Chosen item is {$v}";
};
}
run_random_callable($scoped_functions);
}
/**
* @param callable[] $callables
*/
function run_random_callable($callables) {
$pick = array_rand($callables);
$callables[$pick]();
}
// Will always output 'Chosen item is 10'!
// The list of "scoped functions" will all actually refer to the same $v, updated in the loop
parent_scope();
I don't know if there's some way to make the lifetime even more restricted, so that the use cases of "immediate execution" are allowed, but this kind of code is not.
For something like "run this in a transaction", the closure is really acting like a poor man's "continuation": it creates two new stack frames (transaction wrapper, callback) when what you really want is to interleave the boilerplate and the case-specific code.
In that sense, hygienic macros are probably the "ideal" solution - everything is expanded inline into a single scope, and there's no Closure object which can be misused.
Context Managers could in fact be implemented as such a macro, and as I understand it, the implementation is basically doing that internally by manipulating ASTs.
I wonder if there's any "minimal" macro system which would allow this kind of inline boilerplate expansion, without needing to design an entire meta-language?
Regards,
Rowan Tommins
[IMSoP]
Hey Rowan,
Am 07.05.2026 um 12:52 schrieb Rowan Tommins [IMSoP] imsop.php@rwec.co.uk:
Volker and I drafted a RFC:
Hi Bob,
An I right in thinking that this is essentially equivalent to "automatic capture by closure", with an extra restriction on the lifetime of the resulting closure? It would be good to spell out in the RFC how this compares to other approaches, and other languages.
I think the closest thing to what we propose here is GCC Nested Functions: https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
They have similar lifetime semantics - cannot outlive their declaration scope and cannot be redeclared either (by design because they're named, but scoped function names like that are not a thing in PHP, hence we assign to a variable).
In particular, JavaScript's capture semantics are somewhat notorious as a source of confusion. A common example is creating closures in a loop which all use the same variable; as far as I can see, the proposed semantics would allow this as long as they were executed before the parent scope ends:
function parent_scope() { $values = range(1,10); $scoped_functions = []; foreach( $values as $v ) { $scoped_functions[] = fn($v) { echo "Chosen item is {$v}"; }; } run_random_callable($scoped_functions); } /** * @param callable[] $callables */ function run_random_callable($callables) { $pick = array_rand($callables); $callables[$pick](); } // Will always output 'Chosen item is 10'! // The list of "scoped functions" will all actually refer to the same $v, updated in the loop parent_scope();I don't know if there's some way to make the lifetime even more restricted, so that the use cases of "immediate execution" are allowed, but this kind of code is not.
Have you missed this following restriction and example in the RFC?
Re-evaluation: The same scope function declaration (same source code location) invalidates the previous instance. Should it still be called, an error is raised.
Any scope closure is only allocated a single slot, preventing recursion and double declaration. There are two choices: guaranteeing uniqueness (returning the active Closure again) or invalidating the previous Closure. We chose the second option to avoid the misconception that scope functions would capture the current variables. E.g. in foreach loops, it will always print the current active value and never the value at declaration time.
$closures = [];
for ($i = 0; $i < 3; $i++) {
$closures[] = fn() { return $i; };
}
var_dump($closures2); // int(3)$closures0; // Error: Cannot call scope function: defining scope has exited
This restriction exists exactly because of that issue.
For something like "run this in a transaction", the closure is really acting like a poor man's "continuation": it creates two new stack frames (transaction wrapper, callback) when what you really want is to interleave the boilerplate and the case-specific code.
One thing which this does is interleaving with a well-defined boundary. return works and does not cross the whole function, just the callback.
You don't get a sudden goto or break skipping some of your code. The internal variables of the wrapper frame are isolated and don't leak to you. Argument values to the wrapper are properly type checked.
In that sense, hygienic macros are probably the "ideal" solution - everything is expanded inline into a single scope, and there's no Closure object which can be misused.
With "hygienic" you mean the macro has to produce full expressions, right, i.e. not C preprocessor style.
Context Managers could in fact be implemented as such a macro, and as I understand it, the implementation is basically doing that internally by manipulating ASTs.
I wonder if there's any "minimal" macro system which would allow this kind of inline boilerplate expansion, without needing to design an entire meta-language?
You wonder rightly, but the main problem is the nature of the language/implementation. How would you compile that?
op_arrays are fixed at compile time and not going to change afterwards.
So, you can either try calling functions at compile time to manipulate a functions code (let's say e.g. all !-suffixed function names get called at compile time with some sort of token stream or AST, whatever) or invent very clever hacks to somehow generate op_array snippets on the fly at runtime.
That once-per-request nature of PHP also makes it very difficult to efficiently cache such code (unless you assume every invocation of that function will always output the same, which you cannot even rely on, because every request could invoke a different file defining the same macro etc.).
You will also get interesting behaviours with jumps, e.g. a goto will suddenly ... jump over a bunch of logic, so any macro will have to do try/finally. while loops inside that macros, do they count towards the break/continue stack etc.?
It's a big rabbit hole. You'll find that it's not impossible to do, but it has quite a few trade offs and possibly odd choices to make.
I am not opposed at all to such a consistent macro system though.
... but I would not make a transaction like that a macro. For inlining variables in a html or sql snippet with proper escaping, definitely great.
To me, macros should meaningfully transform their contained code rather than wrapping a bit of logic around, which would be covered by this RFC.
It's complimentary, not a replacement.
Thanks,
Bob
I don't know if there's some way to make the lifetime even more restricted, so that the use cases of "immediate execution" are allowed, but this kind of code is not.
Have you missed this following restriction and example in the RFC?
Re-evaluation: The same scope function declaration (same source code location) invalidates the previous instance. Should it still be called, an error is raised.
I skimmed past that section, and didn't realise its significance, thinking it was just covering off edge cases of the implementation.
I think the core principle behind the various restrictions needs to be made much clearer in the summary of the proposal, because up to that point all the examples just look identical to normal closures with automatic capture by reference.
For similar reasons, perhaps a different keyword would be better, so that users don't have a wrong expectation of what it means.
Regards,
Rowan Tommins
[IMSoP]
I am not opposed at all to such a consistent macro system though.
... but I would not make a transaction like that a macro. For inlining variables in a html or sql snippet with proper escaping, definitely great.
To me, macros should meaningfully transform their contained code rather than wrapping a bit of logic around, which would be covered by this RFC.
It's complimentary, not a replacement.
Thinking about this further, I agree that full-blooded macros would be
overkill for this case, but my starting point was that closures don't
feel like the right solution either - they're a different feature being
bent into shape.
So rather than starting with a Closure, and taking things away, I was
trying to think of ways to start with a simple block of code, and build
it up.
For instance, the array_walk example in the RFC is just an ugly (and
probably inefficient) way of writing a foreach loop:
array_walk($numbers, fn($number) {
$count = bcadd($count, '1');
$sum = bcadd($sum, $number);
});
foreach($numbers as $number) {
$count = bcadd($count, '1');
$sum = bcadd($sum, $number);
}
So, what would it look like to generalise that, so we could do the same
for other scenarios, like async() and transaction()?
A simple first step would be something that could take a block of code,
and say when to execute it:
custom_block transaction($dbConnection) {
try {
$dbConnection->beginTransaction();
__execute_block_body();
}
catch (\Throwable $e) {
$dbConnection->rollbackTransaction();
throw $e;
}
$dbConnection->commitTransaction();
}
transaction($myDb) {
$myDb->query('UPDATE ...');
}
If the block body is never represented as a variable, there's no need to
define what happens when it outlives scope, or the user tries to clone
it, rebind it, etc.
And if the calling code doesn't look like it's creating a Closure, users
won't have any wrong expectations about variable scopes or lifetimes.
Onto that, we can add syntax to push values into the block, e.g. using
the "as" keyword like in "foreach" (example based on the "Generator
decorator managers" section at the end of the Context Managers RFC):
custom_block opening($filename) {
$f = fopen($filename, "r");
if (!$f) {
throw new Exception("fopen($filename) failed");
}
try {
__execute_block_body($f);
} finally {
fclose($f);
}
}
opening(FILE as $f) {
var_dump($f);
}
And some way to pull values out, e.g. a "break with" keyword:
custom_block transaction(DBConnection $conn) {
$conn->beginTran();
try {
if (__execute_block_body() === DBConnection::TRANSACTION_ABORT) {
$conn->rollbackTran();
return;
}
} catch (\Throwable $e) {
$conn->rollback();
throw $e;
}
$conn->commitTran();
}
transaction($connection) {
$affectedRows = $connection->query("UPDATE ...");
if ($affectedRows === 0) {
break with DBConnection::TRANSACTION_ABORT;
}
// ...
}
I'm sure there are details here that wouldn't quite work as expressed,
but hopefully it explains what I meant by wanting something closer to
macros than closures.
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 7 May 2026 at 19:03 Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:
I am not opposed at all to such a consistent macro system though.
... but I would not make a transaction like that a macro. For inlining
variables in a html or sql snippet with proper escaping, definitely great.
To me, macros should meaningfully transform their contained code rather
than wrapping a bit of logic around, which would be covered by this RFC.
It's complimentary, not a replacement.Thinking about this further, I agree that full-blooded macros would be
overkill for this case, but my starting point was that closures don't
feel like the right solution either - they're a different feature being
bent into shape.So rather than starting with a Closure, and taking things away, I was
trying to think of ways to start with a simple block of code, and build
it up.For instance, the array_walk example in the RFC is just an ugly (and
probably inefficient) way of writing a foreach loop:array_walk($numbers, fn($number) {
$count = bcadd($count, '1');
$sum = bcadd($sum, $number);
});foreach($numbers as $number) {
$count = bcadd($count, '1');
$sum = bcadd($sum, $number);
}So, what would it look like to generalise that, so we could do the same
for other scenarios, like async() and transaction()?A simple first step would be something that could take a block of code,
and say when to execute it:custom_block transaction($dbConnection) {
try {
$dbConnection->beginTransaction();
__execute_block_body();
}
catch (\Throwable $e) {
$dbConnection->rollbackTransaction();
throw $e;
}
$dbConnection->commitTransaction();
}transaction($myDb) {
$myDb->query('UPDATE ...');
}If the block body is never represented as a variable, there's no need to
define what happens when it outlives scope, or the user tries to clone
it, rebind it, etc.And if the calling code doesn't look like it's creating a Closure, users
won't have any wrong expectations about variable scopes or lifetimes.Onto that, we can add syntax to push values into the block, e.g. using
the "as" keyword like in "foreach" (example based on the "Generator
decorator managers" section at the end of the Context Managers RFC):custom_block opening($filename) {
$f = fopen($filename, "r");
if (!$f) {
throw new Exception("fopen($filename) failed");
}
try {
__execute_block_body($f);
} finally {
fclose($f);
}
}opening(FILE as $f) {
var_dump($f);
}And some way to pull values out, e.g. a "break with" keyword:
custom_block transaction(DBConnection $conn) {
$conn->beginTran();
try {
if (__execute_block_body() === DBConnection::TRANSACTION_ABORT) {
$conn->rollbackTran();
return;
}
} catch (\Throwable $e) {
$conn->rollback();
throw $e;
}
$conn->commitTran();
}transaction($connection) {
$affectedRows = $connection->query("UPDATE ...");
if ($affectedRows === 0) {
break with DBConnection::TRANSACTION_ABORT;
}
// ...
}
That looks like a function (aka closure) with a lot of weird extra steps.
It’s been years, several proposals and multiple demonstrations on how arrow
function syntax can be expanded to be useful with multi-statements. So much
gymnastics goes on to deny such a simple and elegant syntax.
For something like "run this in a transaction", the closure is really
acting like a poor man's "continuation": it creates two new stack
frames (transaction wrapper, callback) when what you really want is to
interleave the boilerplate and the case-specific code.In that sense, hygienic macros are probably the "ideal" solution -
everything is expanded inline into a single scope, and there's no
Closure object which can be misused.Context Managers could in fact be implemented as such a macro, and as I
understand it, the implementation is basically doing that internally by
manipulating ASTs.
Correct. Absent a macro system like Rust, it's just a one-off compiler "macro" that turns into try-catch-finally.
I wonder if there's any "minimal" macro system which would allow this
kind of inline boilerplate expansion, without needing to design an
entire meta-language?
The PFA implementation does generate new opcodes at runtime and cache them. So such things are possible. Wise to generalize or not is an entirely separate question, though. :-)
--Larry Garfield
Thanks for this RFC, here are my 2cents:
I think the current syntax is too close to current short closures, and
since it allows multiline closures, it would imply that by default all
multiline short closures are scoped, which is not intuitive since
traditional closures don't capture by default.
Instead, I think replacing the fn () { } syntax to add a keyboard
indicating it inherits the scope would drastically help making it more
intuitive.
I would imagine instead something like this:
$externalVar = 0;
$closure1 = scoped fn () => $newVar1 = $externalVar++;
$closure2 = scoped function () {
return $newVar2 = $externalVar++;
};
$closure1();
$closure2();
var_dump($newVar1); // int(0)
var_dump($newVar2); // int(1)
var_dump($externalVar); // int(2)
This way, for the first case, the only new information that scoped
brings is the potential existence of $newVar1 after the closure's
execution, and for the second closure, it makes it explicit that all
variables in the closure's body are shared with the parent scope.
WDYT?
Le 06/05/2026 à 22:09, Bob Weinand a écrit :
Volker and I drafted a RFC:
https://wiki.php.net/rfc/scope-functions
Please consider it and share your feedback.
I hope it will alleviate pain around some of the most common forms of
Closure usage which is "execute this now as part of the called
function", which currently can require a lot of "use ($variables)".For me the primary use case of use ($capturing) was always "I need
this function later and want to explicitly document what escapes my
function". This, however, required this straightforward usage of
Closures to also document every single usage of a variable. Which is
really not that beneficial at all.Thus the scope functions as proposed will be able to fill that gap in
future.Thank you,
Bob
I think the current syntax is too close to current short closures
I agree.
I don't think we need a new keyword, I think the presence of => in the function definition should indicate that scope is captured, like this:
function() => {
// ...
}
To put it another way fn() => foo; would be a syntactically identical version of function() => {return foo;}
Volker and I drafted a RFC:
Hello, I’d like to offer my 2c as PHPStan maintainer. References are really
hard to wrap our head around. To precisely infer types of variables in a
closure that uses variables by reference, we’d have to check where it’s
called and how many times, then go back to the closure body and fill in how
the variables change throughout the lifecycle. When compared to analysing
normal code that doesn’t use references, this is a lot more complicated, I
might say even impossible in some cases.
So I’m not a fan of spreading these semantics in new language features.
Your Scope functions inherit variables from the outer scope as references
by default. Because the syntax looks just like arrow function (but with a
body that allows multiple statements), I’m opposed to the inconsistency in
behaviour: https://3v4l.org/YKu9K#v8.5.3
The references are also the reason why I’d be afraid to write any Scope
function in practice. Starting new scope, usually in a closure, but also in
a function, method, or property hook, should mean I have a clean slate and
I don’t have to review 1 000 lines of code that preceded that function. I
can assign new variables without having to worry about the impact to
surrounding code. This RFC violates that.
This RFC would allow to call functions like array_map with a Scope function
and modify variables that existed before the array_map call. I’d prefer if
people wrote a traditional foreach instead. I don’t think the examples in
the RFC are worth adding a new place references are used, especially hidden
like that, without using the “&” keyword, which is a warning sign about the
code doing something weird, and signalling we should be especially careful
when working with it.
Ondřej Mirtes
Volker and I drafted a RFC:
Hello, I’d like to offer my 2c as PHPStan maintainer. References are really
hard to wrap our head around. [...]
I only just saw this discussion – the combinatorial
explosion Ondřej describes with references and closures
is something I’ve been brushing against while working on
the *scanf() counter fix for PHPStan.
One thought that’s been growing out of that work and the
original %c report php-src GH-19088: what if PHP could
declare the return arity of a function directly?
Something like:
.listing
function fn(): [int, Error|null] { … } // binary return
function fn(): [] { … } // nulary return
function fn(): [int...] { … } // variadic int return (zero or more)
function fn(): [int, ...] { … } // variadic int return (one or more)
The dot-dot-dot '...' borrows the left‑hand type if none
is given (or means mixed if no left type). A call would
destructure naturally:
.listing
[$a, $b, $c] = fn();
// or with null‑filling:
[$a, $b, $c] = fn() + [null, null, null];
This would give the static analyser a fixed skeleton to
hang its inferences on, even when the actual return is
variadic.
The combinatorial explosion of tracking references
through closures would still exist, but the return site
itself would be a clear contract.
The analyser wouldn’t need to guess the shape of the
returned array; it would be declared right there, much
like the counter in PHPStan asks the runtime for the
exact count of placeholders.
This isn’t an RFC – I’m not fond of writing those. It’s
just a paper‑trail: a small idea that emerged from
fixing a decades‑old sscanf bug,
and that might be useful to someone thinking about
return types in the future.
The counter already measures return arity today; a
native syntax would just make that measurement explicit.
I find this ordinarily simplistic and therefore wonder
if there isn't prior art, specifically in PHP for this.
Feel free to send me any references off‑list or ping me
in room 11.
-- hakre