Proposal: Render floats differently from integers in print_r()
| From: | tyson andre | Date: | Sun, 17 Jan 2021 15:57:44 +0000 |
| Subject: | Proposal: Render floats differently from integers in print_r() | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-112914@lists.php.net to get a copy of this message | ||
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