Re: [DISCUSSION] Adding the "is_integer_safe()" function

From: Date: Sat, 26 Jul 2025 16:13:42 +0000
Subject: Re: [DISCUSSION] Adding the "is_integer_safe()" function
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-128241@lists.php.net to get a copy of this message
> 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 value be safely > converted to an integer?", but that implies a different definition - 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 === (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 functions. For instance, > a generic (or generic-like) form: > > function can_lossless_cast<T>(mixed $value): bool > > can_lossless_cast<float>(2 ** 50) === true > can_lossless_cast<float>(2 ** 54) === false > > can_lossless_cast<int>(2 .0** 54) === true > can_lossless_cast<int>(2.0 ** 65) === false > can_lossless_cast<int>(3.5) === false > can_lossless_cast<int>(NaN) === false > > can_lossless_cast<int>('9007199254740991000') == true // less than 2**64 > can_lossless_cast<float>('9007199254740991000') == false // more than 2**53 > > can_lossless_cast<int|float>('9007199254740991000') == true > can_lossless_cast<int|float>('3.5') == 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

« previous php.internals (#128241) next »