Hi internals, Currently, print_r() will print ints and floats in exactly the same way, despite the fact that they are different types and floats may cause a TypeError (or be treated differently from integers, e.g. avro encoding) when used where an integer is expected. This is not documented in https://www.php.net/print_r
I've created https://github.com/php/php-src/pull/6611 , which proposes to have print_r() dump floats such as 1.0 as 1.0, like var_export currently does. ``` php > print_r(1.0); // old behavior, proposed behavior is 1.0 1 php > print_r(1); 1 php > var_export(1.0); 1.0 php > var_export(1); 1 ``` Benefits: - print_r() previously make it look as if a value was an int when it really was a float. When using print_r() to inspect the value of an array, TypeErrors or differences in behavior can be unintuitive if you think the value is really an integer when it's actually a float. This change should save time debugging in the long run for users unfamiliar with this behavior. (https://www.php.net/print_r has no mention of the behavior seen for floats in the summary or user-submitted comments) - print_r() output now shows a difference between 0.0 and 0, which is useful for generating diffs between expected and actual values in test failures, etc. Cons: - Existing tests of php, pecl extensions, and composer libraries need to be changed if they involve the raw output of print_r and dumping float values. If this is merged, tests would need to normalize print_r output or use format string expectations to pass in both 8.0 and 8.1 (or switch to var_dump(), var_export(), etc.) Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
