Hi Tim,
Thank you for your thorough review.
> 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?"
> 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.
Fair point about the JSON specification itself. However, the
real-world issue is JavaScript's Number type limitation (safe integers
only up to 2^53). The fact that it is fine if "every system involved
can deal with 64 bits integers" is true, but nothing guarantees that
all systems involved are systematically x64. Many PHP applications
need to communicate with JavaScript frontends, and knowing when a
numeric ID exceeds JavaScript's safe integer range would improve
interoperability.
> 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.
> 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
- High-precision timestamps in microseconds
- Large auto-increment IDs in mature applications
Hope I addressed your concerns.
Best,
Alexandre Daubois
