Hi
Am 2025-07-29 14:52, schrieb Alexandre Daubois:
I would like to present the RFC to add the
"is_representable_as_float()" and "is_representable_as_int()"
functions. These functions provide developers with a way to check
whether values can be losslessly converted between integer and
floating-point representations.
https://wiki.php.net/rfc/is-representable-as-float-int
Thank you for the RFC. I fundamentally disagree with that there is a
single, obvious and meaningful definition for
`is_representable_as_float()`. In fact right from the beginning of the
“Proposal” section:
The value is a string that represents a valid floating-point number
(e.g., “3.14”, “1e10”, “-0.001”)
3.14 is not exactly representable as a IEEE-754 double-precision
floating point number. The two nearest representable values are
3.14000000000000012434 (this one is the nearest) and
3.13999999999999968026. Returning `true` for
`is_representable_as_float("3.14")` is therefore wrong to me.
The introduction is also wrong. JSON does *not* specify that numbers
must be representable as IEEE-754 double-precision floating point
numbers. The grammar for “Numbers” is independent of any particular
representation and transmitting numbers > 2^53 is perfectly fine if
every system involved can deal with 64 bit integers. Also just casting a
non-representable value to string will break any consumers that are
strongly typed and expect a number rather than a string. So that doesn't
make sense to me either.
I also question how meaningful it is knowing that a given number is
exactly representable as a float when (e.g. a power of two) when almost
any operation on it will incur implicit rounding.
For `is_representable_as_int()` finding a reasonable definition is much
easier, but I don't think I've ever had a use case where I needed to
know whether a non-integer value is exactly representable as an int.
Long story short: What actual real-world problem does this RFC attempt
to solve? The list in the “Introduction” section is not particularly
meaningful with regard to the real world and the JSON example is wrong
as outlined above.
Best regards
Tim Düsterhus