Re: [RFC IDEA] Deprecate legacy type alias functions

Hi Ayesh, Thank you for checking for other discussions on this matter. PHP 8.5 deprecating the legacy cast names like boolean, double, integer and binary in favor of bool, float, int and string feels like a pretty clear step toward cleaning up old type terminology. In that context, the remaining legacy alias functions stand out as inconsistent leftovers. On the usage concern: the nice part here is that this is a pure rename with no semantic change. And compared to seven years ago, it also looks like these aliases are used a lot less in real world code, with most modern codebases already leaning on the canonical names. That makes the ecosystem impact meaningfully smaller than what the 2018 thread was reacting to. Also, codebases that still use is_double are likely to also use the legacy (double) cast, which means they will have to migrate to (float) and is_float anyway. So the additional change from deprecating is_double and doubleval feels fairly limited. I will proceed drafting an RFC so this can be discussed and decided properly. Regards, Jordi On 21 Feb 2026 at 4:03 PM +0100, Ayesh Karunaratne <ayesh@php..watch>, wrote: > > is_double, which is an alias of is_float > > is_integer and is_long, both aliases of is_int > > doubleval, which is an alias of floatval > > > > For reference, is_real was deprecated in PHP 7.4 and removed in 8..0. > > > > > > Hi Jordi, > The mailing list thread you linked is the only discussion I could see too. > > That thread raised a valid concern, that the number of code search > matches is quite significant. We need a strong rationale to deprecate > a function. Functions that are not thread-safe, buggy, insecure, > overloaded with different signatures, or simply no longer necessary > (such as those resource close functions) are quite easy to argue that > deprecating them will lead to a positive outcome. > > is_double|integer|long functions are purely aliases, and they > have > been there in PHP practically forever. Code search results also yield > quite a lot of matches, so deprecating them will add a lot of work to > the package maintainers and users with little to no benefit. We > normally remove the deprecated functions by PHP 9.0, so for thousands > of packages, they cannot simply ignore these deprecations; they become > hard blockers to use PHP 9.0 (assuming you propose to remove them in > PHP 9.0). > > Thank you, > Ayesh.