On 07/05/2026 13:16, Bob Weinand 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;
}
// ...
}
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]
