Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130179
Date: Thu, 26 Feb 2026 22:55:39 +0100
To: Ayesh Karunaratne <ayesh@php.watch>
Cc: internals@lists.php.net
Message-ID: <7a599aa0-c2ce-43e2-a716-b203e7718052@Spark>
In-Reply-To: <CANLbj-rM3-iwOEDt+7mEbAn1WKQVhrHKv9SbQJLod_-gQALfsA@mail.gmail.com>
References: <29443058-75fa-4c36-80cc-3b3a80e0057b@Spark>
 <ae03240a-f4f1-48c7-902b-35dd15f19b69@Spark>
 <CANLbj-rM3-iwOEDt+7mEbAn1WKQVhrHKv9SbQJLod_-gQALfsA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC IDEA] Deprecate legacy type alias functions
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="69a0c163_39afba44_13b3e"
From: jordikroon@me.com (Jordi Kroon)

--69a0c163_39afba44_13b3e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Ayesh,

Thank you for checking for other discussions on this matter.


PHP 8.5 deprecating the legacy cast names like boolean, double, integer a=
nd binary in favor of bool, float, int and string feels like a pretty cle=
ar step toward cleaning up old type terminology. In that context, the rem=
aining legacy alias functions stand out as inconsistent leftovers.


On the usage concern: the nice part here is that this is a pure rename wi=
th no semantic change. And compared to seven years ago, it also looks lik=
e these aliases are used a lot less in real world code, with most modern =
codebases already leaning on the canonical names. That makes the ecosyste=
m impact meaningfully smaller than what the 2018 thread was reacting to.


Also, codebases that still use is=5Fdouble are likely to also use the leg=
acy (double) cast, which means they will have to migrate to (float) and i=
s=5Ffloat anyway. So the additional change from deprecating is=5Fdouble a=
nd doubleval feels fairly limited.


I will proceed drafting an R=46C so this can be discussed and decided pro=
perly.

Regards,
Jordi
On 21 =46eb 2026 at 4:03=E2=80=AFPM +0100, Ayesh Karunaratne <ayesh=40php=
.watch>, wrote:
> > is=5Fdouble, which is an alias of is=5Ffloat
> > is=5Finteger and is=5Flong, both aliases of is=5Fint
> > doubleval, which is an alias of floatval
> >
> > =46or reference, is=5Freal 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 t=
oo.
>
> 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. =46unctions 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.
>
> =60is=5Fdouble=7Cinteger=7Clong=60 functions are purely aliases, and th=
ey 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.

--69a0c163_39afba44_13b3e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hi Ayesh,<br />
<br />
Thank you for checking for other discussions on this matter.<br />
<br />
<br />
PHP 8.5 deprecating the legacy cast names like boolean, double, integer a=
nd binary in favor of bool, float, int and string feels like a pretty cle=
ar step toward cleaning up old type terminology. In that context, the rem=
aining legacy alias functions stand out as inconsistent leftovers.<br />
<br />
<br />
On the usage concern: the nice part here is that this is a pure rename wi=
th no semantic change. And compared to seven years ago, it also looks lik=
e these aliases are used a lot less in real world code, with most modern =
codebases already leaning on the canonical names. That makes the ecosyste=
m impact meaningfully smaller than what the 2018 thread was reacting to.<=
br />
<br />
<br />
Also, codebases that still use is=5Fdouble are likely to also use the leg=
acy (double) cast, which means they will have to migrate to (float) and i=
s=5Ffloat anyway. So the additional change from deprecating is=5Fdouble a=
nd doubleval feels fairly limited.<br />
<br />
<br />
I will proceed drafting an R=46C so this can be discussed and decided pro=
perly.<br /></div>
</div>
<div name=3D=22messageSignatureSection=22><br />
<p style=3D=22caret-color: rgb(213, 218, 222); cursor: text; box-sizing: =
border-box; margin: 0px; padding: 0px; counter-reset: list-1 0 list-2 0 l=
ist-3 0 list-4 0 list-5 0 list-6 0 list-7 0 list-8 0 list-9 0; white-spac=
e: pre-wrap;=22>Regards,</p>
<p style=3D=22caret-color: rgb(213, 218, 222); cursor: text; box-sizing: =
border-box; margin: 0px; padding: 0px; counter-reset: list-1 0 list-2 0 l=
ist-3 0 list-4 0 list-5 0 list-6 0 list-7 0 list-8 0 list-9 0; white-spac=
e: pre-wrap;=22>Jordi</p>
</div>
<div name=3D=22messageReplySection=22>On 21 =46eb 2026 at 4:03=E2=80=AFPM=
 +0100, Ayesh Karunaratne &lt;ayesh=40php.watch&gt;, wrote:<br />
<blockquote type=3D=22cite=22 style=3D=22border-left-color: grey; border-=
left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left:=
 10px;=22>
<blockquote type=3D=22cite=22>is=5Fdouble, which is an alias of is=5Ffloa=
t<br />
is=5Finteger and is=5Flong, both aliases of is=5Fint<br />
doubleval, which is an alias of floatval<br />
<br />
=46or reference, is=5Freal was deprecated in PHP 7.4 and removed in 8.0.<=
br />
<br />
<br /></blockquote>
<br />
Hi Jordi,<br />
The mailing list thread you linked is the only discussion I could see too=
.<br />
<br />
That thread raised a valid concern, that the number of code search<br />
matches is quite significant. We need a strong rationale to deprecate<br =
/>
a function. =46unctions that are not thread-safe, buggy, insecure,<br />
overloaded with different signatures, or simply no longer necessary<br />=

(such as those resource close functions) are quite easy to argue that<br =
/>
deprecating them will lead to a positive outcome.<br />
<br />
=60is=5Fdouble=7Cinteger=7Clong=60 functions are purely aliases, and they=
 have<br />
been there in PHP practically forever. Code search results also yield<br =
/>
quite a lot of matches, so deprecating them will add a lot of work to<br =
/>
the package maintainers and users with little to no benefit. We<br />
normally remove the deprecated functions by PHP 9.0, so for thousands<br =
/>
of packages, they cannot simply ignore these deprecations; they become<br=
 />
hard blockers to use PHP 9.0 (assuming you propose to remove them in<br /=
>
PHP 9.0).<br />
<br />
Thank you,<br />
Ayesh.<br /></blockquote>
</div>
</body>
</html>

--69a0c163_39afba44_13b3e--