Hi
On 8/26/25 19:14, Alexandre Daubois wrote:
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.
You're right about mathematical precision. Perhaps the function name
is misleading. What the function actually should check is whether a
string > float > string roundtrip preserves the value as PHP
developers would expect it, not whether it's mathematically exactly
representable in IEEE-754.
Maybe a more accurate name would better reflect this behavior. Naming
is super hard again here. The goal is pragmatic: "will this value
survive a type conversion cycle without surprising changes?"
"Surprising changes" is not a meaningful term. Keep in mind that the
behavior of the function will need to be accurately documented and that
folks need something to work with to determine whether a report is valid
or not when bugs in the function get reported - which will inevitably
happen.
In fact to use one of the examples for the RFC: 1e10 does not roundtrip.
php > var_dump((string)(float)"1e10");
string(11) "10000000000"
"1e10" clearly is different than "10000000000".
Generally speaking, I'm also not sure if “printing raw floats” is a
use-case we should encourage. Instead almost any application will need
to format a number for a specific use-case. Formatting numbers for human
consumption [1] has different requirements compared to formatting
numbers for programmatic consumption.
Also note that the stringification of floats unfortunately is controlled
by INI settings `precision` and `serialize_precision` which adds
additional complexity.
[1] My recommendation is using ext/intl's NumberFormatter:
https://www.php.net/manual/en/class.numberformatter.php
need to communicate with JavaScript frontends, and knowing when a
numeric ID exceeds JavaScript's safe integer range would improve
interoperability.
For *this* use case we would not need a complex function. A simple
constant FLOAT_INTEGER_RANGE or similar would be sufficient.
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.
To me, the code snippet in the RFC introduction illustrates a valid
use-case of a numeric identifier that could be dangerous to cast.
Please note my remark regarding “strongly typed consumers”. Magically
switching from JSON's number type to JSON's string type for specific
values is needlessly increasing complexity for everyone who interacts
with the JSON payload, particularly for compiled languages. If you know
that the consumers of your JSON are having troubles with certain numbers
you emit and you want to emit strings for those kind of numbers instead,
then you should just emit strings all the time.
In fact I'd argue that using JSON's number type for numeric IDs is
wrong, just like treating phone numbers or zip codes as numbers is
wrong. If it's not reasonable to do math on a value then it's likely not
a number, but instead a numeric string.
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.
A few examples, as interoperability between with JSON/JavaScript is
the main point here, could be:
- Snowflake IDs
At the application boundary these should just be a string, since
consumers of your API should treat IDs as opaque values, unless you want
to give some guarantees (e.g. rough ordering, which would still work
with strings).
- High-precision timestamps in microseconds
Using a number is reasonable here, but see above regarding “magically
switching types”.
(From my experience timestamps are generally represented as ISO-8601
strings in JSON APIs anyways)
- Large auto-increment IDs in mature applications
Same as snowflakes.
Hope I addressed your concerns.
I'm afraid not.
Best regards
Tim Düsterhus
