Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128559
Precedence: list
MIME-Version: 1.0
Date: Tue, 26 Aug 2025 16:30:19 +0200
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Add "is_representable_as_float()" and
 "is_representable_as_int()" functions
In-Reply-To: <CAMU7irKj_SyyM2kVz4kEqjDK+ucc8uRP1amJgASTFRM+V+Ld3w@mail.gmail.com>
References: <CAMU7irKj_SyyM2kVz4kEqjDK+ucc8uRP1amJgASTFRM+V+Ld3w@mail.gmail.com>
Message-ID: <f419f96e3cf4ce194a8d59349a625817@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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