The second parameter to var_export makes the function return the information into a string, so this functionality is already implemented in someway.
(also, IMO having it as an option is not an option :)

Derick

Ok, but what about print_r and var_dump?

I don't like to have three functions doing a similar job but expecting different parameters.

Furthermore the documentation for var_export should be more clearly.
IMO "You can also return the variable representation by using TRUE as second parameter to this function." says it returns just the content of the variable as var_dump($var,true) did some time ago (IIRC).

var_dump  can not be modified, as you can use it to dump more than one variable.
print_r can be modified, but I don't see any reason to do it as var_export() already works fine.

Derick

The output from print_r and var_export (and var_dump) differs. For example: I usually use var_dump because it shows me the datatype of the variable.

Why should I renounce of some information because I want it as string and not as direct output?

When I have something in my vars that should be escaped for HTML I'll get a messed up output because I can't do that:

echo htmlentities(var_dump($html_debug,TRUE));
or 
echo htmlentities(print_r($html_debug,TRUE));

var_dump() sucks within HTML - even after a <pre>. Since PHP's output goes to an web browser in most cases, I should have the capability to produce HTML save debug informations.

(And no, it's not a good idea to make the default output of var_dump HTML save, php-cli users would complain.)

So please, update print_r and add a function that does the same as var_dump but returns a string.

Really, if print_r is going to return instead of output, then we should really rename the function to something like array_dump (much better, less cryptic name) and then have an optional callback on it, such as htmlspecialchars or wordwrap (or a custom function).  The output of print_r makes people extremely statisfied when debugging and i don't think than any other output method sums it up quite as well.

Currently I'm not interested in what print_r does or can do. But I'd like to have a function that dumps all vars with datatypes into a string, like var_dump. We should find a solution which keeps convenient for future needs.

What about giving var_export a third parameter which defines the style of output / return string. Then in future you don't have to add new functions if you need an other way of depicting variables. You would just have to add a new possible value for the third parameter.

If this feature will be implemented, you should throw a warning (which can be suppressed by a '@') if the third parameter is invalid and use the default style for backward compatibility.

Examples:

// direct output, style php-like
var_export( $var );
var_export( $var, false );
var_export( $var, false, 'p' );

// returning a string, style php-like
var_export( $var, true );
var_export( $var, true, 'p' );

// direct output, style minimal (like print_r)
var_export( $var, false, 'm' );

// returning a string, style minimal (like print_r)
var_export( $var, true, 'm' );

// direct output, style detailed (like var_dump)
var_export( $var, false, 'd' );

// returning a string, style detailed (like var_dump)
var_export( $var, true, 'd' );

ob_start();
var_dump ($myvar);
$data = ob_get_contents();

Of course you can easily wrap this in a function. Var_dump can not be changed because of Backward Compability, and var_export() is NOT meant to dump all information, but generate a string representation of a variable that can be parsed as PHP code.

I'm going to close this now, feel free to submit a patch.

Derick