I’d like to gauge interest in adding two debugging functions to PHP core: dd() and dump().
Background
Currently, developers rely on userland solutions like Laravel’s dd() helper or Symfony’s VarDumper for enhanced debugging output. These tools are widely adopted across the PHP ecosystem, suggesting strong demand for better debugging primitives.
Proposal Overview
dd($var, …$vars) - “dump and die” - outputs formatted debug info and terminates execution
dump($var, …$vars) - outputs formatted debug info and continues execution
Enhanced Features Over Existing Solutions
Native performance (no userland overhead)
Stack trace integration
Memory usage reporting
Execution timing (potentially)
Better CLI formatting
Why Core vs Userland?
Similar to how var_dump() provides basic introspection, these functions would offer enhanced debugging capabilities that benefit the entire ecosystem, not just framework users.
Implementation
I’m seeking collaboration with an experienced PHP core developer for the C implementation. I can handle the RFC documentation, testing, etc. I have experience with the Laravel/Symfony codebases.
Before drafting a formal RFC, I’d appreciate feedback on:
General appetite for enhanced debugging functions in core
Concerns about naming conflicts with existing userland helpers
On Tue, Jun 17, 2025, at 2:54 PM, Braunson Yager wrote:
Hi internals,
I'd like to gauge interest in adding two debugging functions to PHP
core: dd() and dump().
*Background*
Currently, developers rely on userland solutions like Laravel's dd()
helper or Symfony's VarDumper for enhanced debugging output. These
tools are widely adopted across the PHP ecosystem, suggesting strong
demand for better debugging primitives.
*Proposal Overview
*- dd($var, ...$vars) - "dump and die" - outputs formatted debug info
and terminates execution
- dump($var, ...$vars) - outputs formatted debug info and continues
execution
*Enhanced Features Over Existing Solutions
*- Native performance (no userland overhead)
- Stack trace integration
- Memory usage reporting
- Execution timing (potentially)
- Better CLI formatting
*Why Core vs Userland?
*Similar to how var_dump() provides basic introspection, these
functions would offer enhanced debugging capabilities that benefit the
entire ecosystem, not just framework users.
*Implementation*
I'm seeking collaboration with an experienced PHP core developer for
the C implementation. I can handle the RFC documentation, testing, etc.
I have experience with the Laravel/Symfony codebases.
*Before drafting a formal RFC, I'd appreciate feedback on:
*1. General appetite for enhanced debugging functions in core
2. Concerns about naming conflicts with existing userland helpers
3. Preferred feature scope
Thoughts?
Best regards,
Braunson Yager
What exactly would dump() offer that's different/better than var_dump() already does today? Is it just a pretty-printed var_dump()? I don't really see a need for that.
While I understand that dd is a valid way of debugging PHP code, I don’t think we should encourage this. Users should be encouraged to learn how to use proper debugger like XDebug. Plus PHP has plenty of dumping functions already and I see no need for yet another one.
While I understand that dd is a valid way of debugging PHP code, I don't think we should encourage this. Users should be encouraged to learn how to use proper debugger like XDebug. Plus PHP has plenty of dumping functions already and I see no need for yet another one.
One could probably, easily, write a userland script that accomplished dd() via the XDebug protocol.
On Tue, Jun 17, 2025, at 2:54 PM, Braunson Yager wrote:
Hi internals,
I’d like to gauge interest in adding two debugging functions to PHP
core: dd() and dump().
Background
Currently, developers rely on userland solutions like Laravel’s dd()
helper or Symfony’s VarDumper for enhanced debugging output. These
tools are widely adopted across the PHP ecosystem, suggesting strong
demand for better debugging primitives.
*Proposal Overview
*- dd($var, …$vars) - “dump and die” - outputs formatted debug info
and terminates execution
dump($var, …$vars) - outputs formatted debug info and continues
execution
*Enhanced Features Over Existing Solutions
*- Native performance (no userland overhead)
Stack trace integration
Memory usage reporting
Execution timing (potentially)
Better CLI formatting
*Why Core vs Userland?
*Similar to how var_dump() provides basic introspection, these
functions would offer enhanced debugging capabilities that benefit the
entire ecosystem, not just framework users.
Implementation
I’m seeking collaboration with an experienced PHP core developer for
the C implementation. I can handle the RFC documentation, testing, etc.
I have experience with the Laravel/Symfony codebases.
*Before drafting a formal RFC, I’d appreciate feedback on:
*1. General appetite for enhanced debugging functions in core
2. Concerns about naming conflicts with existing userland helpers
3. Preferred feature scope
Thoughts?
Best regards,
Braunson Yager
What exactly would dump() offer that’s different/better than var_dump() already does today? Is it just a pretty-printed var_dump()? I don’t really see a need for that.
–Larry Garfield
You should give dump() a try Larry, the benefits are self-explanatory
About the proposal itself, as the author of Symfony’s VarDumper (which is also what Laravel uses under the hood), I’m definitely against it: having the implementation in userland gives way more freedom to innovate on the topic. Eg the number of casters is increasing version after version. Moving this capability to php-src devs would kinda freeze everything. About casters, it’s an API provided by VarDumper to define per-type custom representation logic. (There are more APIs provided by the component, and used by third parties, eg PsySH). This aspect is ignored in the state of the proposal.
About the naming dump/dd: while php-src could ignore that these functions are widely used in userland, it should NOT, so the name should be different.
About the perf benefit, it’s void to me: I’m not aware of anyone using dumps in perf-critical code paths (the existing logic is already optimized enough for all practical use cases.)
Then remains the will to make this work out of the box. I tend to agree with this but the proposed solution has too many drawbacks (the main ones listed above). It should be noted that symfony/var-dumper is a standalone component, so one can trivially use it outside of any framework. Just require it and you’ll have the functions in any PHP apps.
