Proposal: Distinguish between float and int in print_r() output.

[TysonAndre]

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 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 asserting values are ===, etc.

Cons:

• Existing tests 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
  to pass in both 8.0 and 8.1 (or switch to var_dump(), etc.)

php > print_r(1.0);  // old behavior
1
php > print_r(1);
1
php > var_export(1.0);
1.0
php > var_export(1);
1

TODO: Fix remaining test failures

[TysonAndre]

https://externals.io/message/112914#112915

This is the same behaviour as print (and asecho). Note also that there is also no distinction for print/print_r in rendering the string "1", the integer 1, and the booleantrue. I think that the original intention of print_r was to have a “recursive” version of print.

If some action is to be taken, I suggest to deprecate print_r.

php > print_r([null, false, true]);
Array
(
    [0] => 
    [1] => 
    [2] => 1
)