Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128241
Precedence: bulk
MIME-Version: 1.0
References: <CAMU7irKKsXxe4j07tsiW45=EWt=fE56Wcz0tdXjdbhYkW3AhJw@mail.gmail.com>
 <BCD461E2-825D-472B-88D9-83435FFBC86A@rwec.co.uk> <CAMU7ir+CQuNZ--=bVZiuOu7QNv4M++pk1HXSgMkVNyekBSYaDA@mail.gmail.com>
 <d9112e11-d06f-42c5-abf9-82d41b5e6d6f@rwec.co.uk>
In-Reply-To: <d9112e11-d06f-42c5-abf9-82d41b5e6d6f@rwec.co.uk>
Date: Sat, 26 Jul 2025 18:13:42 +0200
Message-ID: <CAMU7irJZbNv0-tuNb6wRUx8+3pnLiXzmfihX+6RrhKBy9-wh1Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] Adding the "is_integer_safe()" function
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

> That suggests maybe the name should communicate "safe for JavaScript"; or=
 more generally "safe for 64-bit IEEE floating point".
>
> is_safe_for_js()
> is_safe_for_float()

I'm not sure we should mention Javascript, because it's actually
related to floating point storage.

> I'm not sure if accepting floats in the same function makes sense. If the=
 question is "can this value safely be stored in a float?" and you give it =
a float, then the answer is surely "yes". You have no way of knowing if it =
_already_ lost precision during a previous operation.
>
> Possibly there could be a separate function which asks "can this float va=
lue be safely converted to an integer?", but that implies a different defin=
ition - it wouldn't make much sense to answer "yes" for 3.5, or NaN.

I think we can see this function more like "can this number be
compared safely?", e.g. `var_dump(2**53 =3D=3D=3D (2**53)+1);` returns true
as these numbers are not in the safe interval. A name like
`is_safely_comparable()` would fit better maybe.

> My thinking is that this needs new syntax, to avoid dozens of specific fu=
nctions. For instance, a generic (or generic-like) form:
>
> function can_lossless_cast<T>(mixed $value): bool
>
> can_lossless_cast<float>(2 ** 50) =3D=3D=3D true
> can_lossless_cast<float>(2 ** 54) =3D=3D=3D false
>
> can_lossless_cast<int>(2 .0** 54) =3D=3D=3D true
> can_lossless_cast<int>(2.0 ** 65) =3D=3D=3D false
> can_lossless_cast<int>(3.5) =3D=3D=3D false
> can_lossless_cast<int>(NaN) =3D=3D=3D false
>
> can_lossless_cast<int>('9007199254740991000') =3D=3D true // less than 2*=
*64
> can_lossless_cast<float>('9007199254740991000') =3D=3D false // more than=
 2**53
>
> can_lossless_cast<int|float>('9007199254740991000') =3D=3D true
> can_lossless_cast<int|float>('3.5') =3D=3D true

I really like the idea of generic functions, I however imagine it
would bring a lot more complexity and really profound changes to the
engine, well beyond the scope of the proposal. Maybe the better naming
of the function would solve this?

Best,
Alex