Adding $return would not work: how would var_dump() know that you aren't trying to dump a bool(true) but passing a special argument?

This would have to be a new function, eg. var_dump_r or var_rdump.

You are right, an oversight. Thanks.

A new function (I would find the var_dump_r suggestion the most consistent) would indeed be a possibility. But it seems that adding yet another function might not be very scaleable, these three already feel quite ad hoc invented, while they are quite similar: represent some variable as text.

I would propose to add a 3rd $format argument (optional) to var_export (which I think has to most concise name):
PRINTR_PARSABLE - default option, current output format of var_export
PRINTR_HUMAN - current output format of print_r
PRINTR_TYPED - current output format of var_dump

The main benefit with only these 3 constants would be allowing var_dump output format to be returned as string in a consistent way. print_r would become redundant.

This would allow other formats to be added without a further need to be creative with similar sounding function names.

You say "other formats"...

print_r and var_dump are debugging functions. They shouldn't be used for "practical" purposes like serialization or storage so there isn't much room for improvement - however since print_r can output or return a string, it makes sense for there to be output and return-a-string versions of var_dump.

But other formats? What for? If either function doesn't provide specific information that's would assist debugging then it should be added, but neither of them are really appropriate for anything other than a human to read.

Number of var_dump() args are variable, so we cannot add flag for returning string.
http://php.net/manual/en/function.var-dump.php

Use output buffer if you need to get output as string.

ob_start();
var_dump($foo);
$dump = ob_get_clean();

Oops, I didn't notice comments.
Anyway, writing your own var_dump() with output buffer should be easy.

Thanks for documenting the workaround. Of course I could start writing my own version of this standard method, but for me this ticket is about improving the offering to all PHP users.

Regardless whether we ever need other formats I think the proposal above would harmonize 3 very similar functions in one without breaking backwards compatibility. That on top adding a feature in SPL that prevents people having to write their own version of var_dump.

Since this ticket was closed before even reading the proposal in the comments I would like to ask to put it back to Open, allowing to consider this proposal:

I would propose to add a 3rd $format argument (optional) to var_export (which I think has to most concise name):
EXPORT_PARSABLE - default option, current output format of var_export
EXPORT_HUMAN - current output format of print_r
EXPORT_TYPED - current output format of var_dump

> I would propose to add a 3rd $format argument (optional) to
> var_export (which I think has to most concise name):
> EXPORT_PARSABLE - default option, current output format of var_export
> EXPORT_HUMAN - current output format of print_r
> EXPORT_TYPED - current output format of var_dump

That would require an RFC, anyway. <https://wiki.php.net/rfc/howto>
explains how that is done.