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

Reply via email to