Proposal: short_var_export($value, bool $return=false, int $flags=0)

Hi internals, I've created a PR https://github.com/php/php-src/pull/6619 to add an alternative to var_export(). The proposed short_var_export() also outputs/returns a parseable representation of a variable, but adds requested features for var_export. 1. Use null instead of NULL - the former is recommended by more coding guidelines (https://www.php-fig.org/psr/psr-2/). 2. Change the way indentation is done for arrays/objects. See ext/standard/tests/general_functions/short_var_export1.phpt (e.g. always indent with 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as "[\n 'item1',\n]" rather than "array(\n 0 => 'item1',\n)" 4. Prepend \ to class names so that generated code snippets can be used in namespaces (e.g. with eval()) without any issues. 5. Support opt-in SHORT_VAR_EXPORT_SINGLE_LINE in int $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. ("['item']") Changing var_export() itself has been proposed 9 months ago (https://externals.io/message/109415) but the RFC discussion seems to be on hold. https://externals.io/message/106674#106684 suggested adding a new function as an alternative. One of the major objections is that changing var_export() (instead of adding a new function) would have these drawbacks: 1. It would be impractical to backport/polyfill calls with 3 args to older php versions, if int $flags was added. ArgumentCountErrors are thrown in php 8.0 for too many parameters, and earlier php versions warn 2. If defaults were changed, then thousands of unit tests in php-src and other projects may fail due to tests expecting the exact representation of a variable, requiring a lot of work to update tests I feel like the user-friendliness of the enhancements makes adding another function to PHP worth it. (e.g. copying short_var_export() into a code snippet such as the expectation for a unit test or a configuration) I don't believe I've seen an RFC for a separate function before. Also, a native C implementation would be much more efficient than a polyfill implemented in PHP, e.g. https://github.com/brick/varexporter/issues/14 I plan to start an RFC document shortly. Thoughts? (e.g. for the name, short_var_export() seemed more appropriate than var_export_short(), pretty_var_export() or canonical_var_export()) Thanks, - Tyson