ext/standard: Add dd function

[nunomaduro]

edit: this pull request is in draft and not ready for review because it was created for the purpose of explaining to the community how they can contribute to PHP’s source code.

here is the video on it: youtu.be/FBtPOg5GxYA?si=MrTPPldwhHKaokcJ

[TimWolla]

Given the obvious conflict with userland, this will require an RFC.

[TimWolla]

Besides the one technical remark, this will also require tests (including tests where the var_dump() itself throws an exception).

[TimWolla]

Bailouts are mainly to be used for “unclean” exits. Use zend_throw_unwind_exit() instead.

[mbeccati]

Why would we want this in core php?

[roxblnfk]

The biggest objection here is the userland conflict, and I think it can be turned into the strongest argument for a well-designed version of this feature.

The current implementation is var_dump() + script termination, which makes sense as a default. But dd is already deeply entrenched in userland, and not as a thin var_dump wrapper. Tools build real infrastructure on top of it: dumpers ship custom casters that change how specific classes are rendered (e.g. trap patches Symfony's var-dumper to display protobuf messages sanely), and dump servers like Buggregator collect dumps over the wire and render/aggregate them remotely. A core dd that always falls back to var_dump and exits would silently bypass all of that — which is exactly the kind of ecosystem breakage the Requires RFC label is about.

So if this goes the RFC route, I'd argue the handler is not an optional extra — it's the core of the design. Expose a way to register a custom dd handler, falling back to the current var_dump-and-exit behavior when none is set:

set_dump_handler(function (DumpStructure $dump): void {
    // framework/tool decides how to render, where to send, when to exit
});

Frameworks and tools override it; everyone else gets the default.

There's an upside beyond not-breaking-things. Today dumpers resort to reflection and some hacks to extract complete information from a value. If the handler receives a structured representation of the dumped value (DumpStructure above) rather than a pre-formatted string, you'd give the ecosystem a clean extraction point and remove a whole class of those hacks.

[youkidearitai]

I'm confuse because already there is dl function in PHP.
Please explain why name is dd in the RFC.

[andrey-helldar]

Why would we want this in core php?

Because, Symfony and Laravel is future 😀

[bibrokhim]

Please explain why name is dd in the RFC.

Dump and Die

[LamentXU123]

Thank you for contributing to php. As this is adding a new function, it would be appreciated to add corresponding tests into the pull request to make sure things work. You might also need to fix the stub error in CI. Also, we generally requires a RFC to let the majority of the community to vote for new features. See here for guidance in how to launch a RFC process.

[markuszeller]

Please only implement self explaining function names. dump_die() would fit better.

[ssddanbrown]

On their video the author has commented:

Commenter: RFC voting war begins 🍿
Author: ahah, i won't actually do an RFC with this.. you crazy ahah

Just pointing that out in case maintainers were spending time on this, expecting an RFC.

[youkidearitai]

Okay, I'll close.
Actually maintenance cost is increased.