[RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions

Hi internals,

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

Best,
Alexandre Daubois

This looks lovely.

Since only int, float, and string can ever be true, does it make sense
to type the function parameters as int|float|string rather than mixed,
to automatically exclude arrays, objects, and null? (All of which would
always be false.)

There is prior art and also I'd personally recommend to abide to mixed to
not open new gaps while closing older.

 php --rf is_countable
 Function [ <internal:standard> function is_countable ] {
 
   - Parameters [1] {
     Parameter #0 [ <required> mixed $value ]
   }
   - Return [ bool ]
 }

(I could probably argue either way on it, but my first inclination is
yes; push the initial validation upstream. You should always know if a
variable is a primitive or not, at the very least.)

IMHO this is not a validation but a test function.

So if you think one should know, you probably should not need this function
at all.

Btw. is_primitive() was not a thing last time I looked. It would be great
though to have the combined test of is_scalar() and is_null() in a single
function call.

This is perhaps something for the line-up.

Just my 2 cents

-- hakre

Since frameworks already have things like Strings::is_stringable() and Arr::arrayable(), I'd suggest to use is_floatable(), is_intable() or is_integerable(), etc.
To me, this would also feel more consistent is is_float(), is_int(), etc.

I get what you mean. Naming is definitely challenging here. However,
with alternatives like "is_floatable()", I'm afraid that it is not
clear enough that there's a potential loss of precision. I would
personally feel that "is_floatable()" would mean "can this be cast to
float?" without further "limitation".

Best,
Alexandre Daubois

The value is a float that is not NaN or infinity

It feels a bit odd to have a value where is_float($v) would be true, but is_representable_as_float($v) would be false. I'd be interested to understand the thinking behind this case.

As the strings “INF” and “NAN” can't be cast as floats directly, I
think it's safer to return false on these extreme values. See
https://3v4l.org/TabMK#vnull for the cast example.

I suggest removing that sentence and example completely. There is nothing the function can or should do differently on different platforms.

You are right, it's misleading. I'll update the RFC accordingly.

This one is fair enough, but I'd suggest tweaking the example slightly to avoid the same problem with different inputs: on a 64-bit build, 2**31 already is an integer, so it's trivially true. So either force a floating point input:

is_representable_as_int(2.0**31); // true on 64-bit platforms, false on 32-bit platforms

or, perhaps clearer, use an out-of-range string input:

is_representable_as_int('2147483648'); // true on 64-bit platforms, false on 32-bit platforms

I'll also update accordingly. Thank you!

Best,
Alexandre Daubois

On Tue, Aug 12, 2025 at 4:35 AM Alexandre Daubois <
alex.daubois+php@gmail.com> wrote:

Hi Internals,

This is a friendly reminder that this RFC has been under discussion
for a couple of weeks. Today marks two weeks since the announcement of
this RFC. After some uneventful discussions, I am wondering how we
should proceed now. Would you like to continue the discussion, or
perhaps initiate a vote? With the feature freeze imminent (tomorrow,
if I'm right?), I am not sure that the RFC would be implemented in 8.5
if it is accepted given that the vote lasts at least a week.

It is too late for RFCs to target PHP 8.5; they needed to finish voting
today in order to be included.

Given that this cannot be included in PHP 8.5, I would suggest waiting at
least a few weeks before starting the vote - some people (myself definitely
included) may not have had a chance to review the RFC because of the work
surrounding trying to finalize and implement things before the PHP 8.5
freeze.

-Daniel

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

I have multiple times just recently had need of "I have a numeric string, should I cast it to an int or a float?", for which an is_representable_as_int() function (or similar) would be quite helpful, and neater than the messy solution I usually use.

I haven't had a use for is_representable_as_float() that I can recall.

--Larry Garfield

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