WIP: Zend: add native defer keyword (parser/compiler + VM opcodes)

[khaledalam]

Inspired by Zig's "defer", it schedules a block to run when the current function exits (return, exception, or natural end), executed in LIFO order, aimed at safer cleanup without repetitive try/finally scaffolding.

• Add T_DEFER token and ZEND_AST_DEFER AST node
• Compile defer blocks by emitting a skip JMP + trailing JMP back
• Add DEFER_PUSH/DEFER_RUN VM handlers using per-call defer_stack
• Run defers before explicit/implicit returns (LIFO)
• Add initial PHPT tests (basic/LIFO/early return/vars); exception unwind not yet supported

[iluuu1994]

Hi @khaledalam. I'm skeptical of this approach.

It effectively mirrors FAST_CALL/FAST_RETURN, which is already quite complex, and causes issues for the optimizer. Deferring until return is very problematic for loops, which with finally would trigger at the end of the current iteration. This will scheule a huge number of defers for long-running functions. Furthermore, any referenced variable in the defer might have long changed to something else by the time the defer is executed.

FWIU Zig executes defer at the end of the current scope. PHP doesn't have true scopes, which would make that somewhat unprecedented. But deferring until return is a no-go, IMO. Zig also doesn't need to think about exceptions, as those aren't a thing there.

Also note there are two recent, competing RFCs that are similar.

https://wiki.php.net/rfc/optin_block_scoping
https://wiki.php.net/rfc/context-managers

[DanielEScherzer]

https://packagist.org/packages/wikimedia/scoped-callback may solve what you are looking for, runs a function via a variable destructor when the variable goes out of scope

[khaledalam]

Hi @khaledalam. I'm skeptical of this approach.

It effectively mirrors FAST_CALL/FAST_RETURN, which is already quite complex, and causes issues for the optimizer. Deferring until return is very problematic for loops, which with finally would trigger at the end of the current iteration. This will scheule a huge number of defers for long-running functions. Furthermore, any referenced variable in the defer might have long changed to something else by the time the defer is executed.

FWIU Zig executes defer at the end of the current scope. PHP doesn't have true scopes, which would make that somewhat unprecedented. But deferring until return is a no-go, IMO. Zig also doesn't need to think about exceptions, as those aren't a thing there.

Also note there are two recent, competing RFCs that are similar.

https://wiki.php.net/rfc/optin_block_scoping https://wiki.php.net/rfc/context-managers

Thanks @iluuu1994 totally fair points. I didn’t fully account for the optimizer complexity until I started implementing this and ran into test regressions, and I also underestimated the real complexity/semantics in loops (accumulating defers across iterations).
I’ll review the linked RFCs and rethink the feature direction, and I’ll keep this PR as a PoC while I fix the current crashes.

[khaledalam]

https://packagist.org/packages/wikimedia/scoped-callback may solve what you are looking for, runs a function via a variable destructor when the variable goes out of scope

Thanks @DanielEScherzer, good pointer. I actually built something very similar in userland (scoped-callback style). My motivation for exploring this in core is mainly language-level ergonomics and avoiding overhead in hot paths, but given the feedback here I'll re-evaluate the direction and how it overlaps with existing solutions/RFCs.

[inxilpro]

I just recently used a defer in Swift and thought to myself, "this would be nice in PHP!"

Would love to see this happen!

One thing I thought was, we could possibly reuse the finally keyword if there's concern about introducing a new language keyword. Effectively:

finally { ... }

Would operate as though the current scope was in a try block.

Either way, I'm excited about the prospect of this!

[francislavoie]

For some more prior art, I use https://github.com/php-defer/php-defer/blob/5.0/src/functions.inc.php which is kinda Go-like, most typically for doing a DB rollback "if the current scope didn't successfully commit", essentially.

One thing to note, Xdebug causes this approach to fail due to https://bugs.xdebug.org/view.php?id=2222, it holds onto references in stack traces longer than it should so it breaks the predictability of destructors being called at the end of a function scope when its last variable ref goes away.