Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128291
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 29 Jul 2025 11:14:46 +0200
To: "Gina P. Banyard" <internals@gpb.moe>,
 "Ilija Tovilo" <tovilo.ilija@gmail.com>
Cc: "PHP internals" <internals@lists.php.net>
Message-ID: <2338ef4d-e9d3-4b16-9b52-8d343976d06d@app.fastmail.com>
In-Reply-To: 
 <-EPNf2A21qLIrIyEvNmQxV_tNTa1IO5hU-LHGBhjfnVRB33qiwK3yhVV7AxDKSTDUl9ihRpapZLckSgnCn7t9RvUj9Jbtjnx1VLYqCQO6BI=@gpb.moe>
References: 
 <ClHWqZ8xQp5NMLvOxMZ80CqdIr0QVhrCzJmDZyw0h7Z4CtK3DG8fW3dKbf4fu-WJRxvqBY9S_W29um3mHEaGJ9ee1epItOizujB3CpbNKfA=@gpb.moe>
 <EYKUX_e3wzCF2eOwU5beLQfcpz-0w4K1M5fjdITFJ0yND11XWgFm-bI_zh7hz8sNygSLrRLe8sTWz_vpcXPlq5o83R5QKfI_zxNzMu1w9eU=@gpb.moe>
 <3b303d303708b13a2de81dc07753da3a@bastelstu.be>
 <qHqe_cprXfMx8PAHwaMVUGmJWu94iC0thiRRjwn_hesackCjF6vbZXLie269X7_4AdHcs9By6j_gZX0L6E5aGjHctUCUESFPbC1sDLHd4EE=@gpb.moe>
 <CAPyj-LC03m4RmxBpZJSOdX3EStPRJu2BrRzE971kn-cyZLmHDw@mail.gmail.com>
 <-EPNf2A21qLIrIyEvNmQxV_tNTa1IO5hU-LHGBhjfnVRB33qiwK3yhVV7AxDKSTDUl9ihRpapZLckSgnCn7t9RvUj9Jbtjnx1VLYqCQO6BI=@gpb.moe>
Subject: Re: [PHP-DEV] [RFC] Warnings for PHP 8.5
Content-Type: multipart/alternative;
 boundary=3905c80bfbfa48e1903e1a1c0ddb2b0d
From: rob@bottled.codes ("Rob Landers")

--3905c80bfbfa48e1903e1a1c0ddb2b0d
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 29, 2025, at 11:01, Gina P. Banyard wrote:
> On Monday, 28 July 2025 at 19:08, Ilija Tovilo <tovilo.ilija@gmail.com=
> wrote:
>=20
> > Hi Gina
> >=20
> > On Mon, Jul 28, 2025 at 7:15=E2=80=AFPM Gina P. Banyard internals@gp=
b.moe wrote:
> >=20
> > > I find it increasingly frustrating that trying to make PHP not be =
completely insane is met with resistance at every turn,
> > > and I'm once more at the stage that I really should stop wasting m=
y time and caring about PHP and do something better with my life.
> >=20
> >=20
> > I appreciate all the work you have put into PHP. However, I don't
> > think threatening to quit PHP over disagreements (which is not the
> > first time either, I believe) creates a healthy environment for
> > discussion. Internals should not fear voicing their concerns. I also
> > believe the concern is not technical, and this would have no trouble
> > passing in the next version.
> >=20
> > Ilija
>=20
> Hi Ilija,
>=20
> Let's take a breath and review what's going on.
>=20
> My original proposal was to warn when type juggling NAN, as this is un=
expected=20
> behaviour, and this was discussed on the mailing list.  Then, just this
> Saturday, Claude pointed out that INF also has this problem (casting I=
NF to int
> produces zero, which is even more clearly a problem).  After confirmin=
g this
> and thinking about it, I wanted to modify my existing wording to accou=
nt for
> this edge case; doing so would have resulted in very convoluted langua=
ge,
> however, so instead I added the new proposal to make it clear this is =
a closely
> related but even more narrow change.
>=20
> This is the highest possible bar that I have set: adding the new edge =
case as a
> secondary vote would have been completely justified, and this would re=
quire a
> smaller majority of a vote.  If I was worried about a procedural spann=
er in the
> works, I could have just shoehorned this minor change into the existin=
g text
> and this would also have been completely justified.  I made the change=
s in the
> clearest possible way for the benefit of people reading the wiki.
>=20
> I will now open the vote as-is, anyone is free to convince people to s=
imply
> vote against it, or do the most procedurally correct thing of starting=
 an RFC
> to render it void after the fact (regardless of the outcome of this vo=
te).
>=20
> Regarding the suggestion to simply kick the can down the road to the n=
ext
> version: we do not know if the next version will be 9.0, which if the =
same
> request is made about deprecation as 8.0 had, this would mean the warn=
ing for
> this could not be introduced until 9.1, and then it could only be upgr=
aded to
> an error by PHP 10.0. This seems like a disproportionate amount of ext=
ra work
> for such a minor change.
>=20
> I agree it is important for internals to voice their concerns.  I am s=
imply
> upset that a very minor *procedural* disagreement is once again incent=
ivising
> me to smuggle in common-sense changes through procedural back doors ra=
ther than
> write my proposals clearly.  This seems like a clearly positive and mi=
nor
> change; anyone who disagrees on *technical* grounds can vote no, and i=
f the
> procedural issue really is so important, there is a recourse available=
 for
> this.  Having to fight these kinds of battles over my work to improve =
the
> language is needlessly taxing, and this too is a form of unhealthy env=
ironment.
>=20
>=20
> Best regards,
>=20
> Gina P. Banyard

I am not sure that (int)"INF" or (int)"NAN" is misbehaving. (int)"Passwo=
rd" also produces `0`, and these are strings. If we had the time to disc=
uss it properly, I would argue that simply warning when casting a string=
 to int is the most sensible thing, just like we get an error when coerc=
ing a string to int, which is more consistent across the language than j=
ust special casing some strings.

=E2=80=94 Rob
--3905c80bfbfa48e1903e1a1c0ddb2b0d
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, Jul =
29, 2025, at 11:01, Gina P. Banyard wrote:</div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div>On Monday, 28 July 2025 at 19:08, Ilija Tovi=
lo &lt;<a href=3D"mailto:tovilo.ilija@gmail.com">tovilo.ilija@gmail.com<=
/a>&gt; wrote:</div><div><br></div><div>&gt; Hi Gina</div><div>&gt;&nbsp=
;</div><div>&gt; On Mon, Jul 28, 2025 at 7:15=E2=80=AFPM Gina P. Banyard=
&nbsp;<a href=3D"mailto:internals@gpb.moe">internals@gpb.moe</a> wrote:<=
/div><div>&gt;&nbsp;</div><div>&gt; &gt; I find it increasingly frustrat=
ing that trying to make PHP not be completely insane is met with resista=
nce at every turn,</div><div>&gt; &gt; and I'm once more at the stage th=
at I really should stop wasting my time and caring about PHP and do some=
thing better with my life.</div><div>&gt;&nbsp;</div><div>&gt;&nbsp;</di=
v><div>&gt; I appreciate all the work you have put into PHP. However, I =
don't</div><div>&gt; think threatening to quit PHP over disagreements (w=
hich is not the</div><div>&gt; first time either, I believe) creates a h=
ealthy environment for</div><div>&gt; discussion. Internals should not f=
ear voicing their concerns. I also</div><div>&gt; believe the concern is=
 not technical, and this would have no trouble</div><div>&gt; passing in=
 the next version.</div><div>&gt;&nbsp;</div><div>&gt; Ilija</div><div><=
br></div><div>Hi Ilija,</div><div><br></div><div>Let's take a breath and=
 review what's going on.</div><div><br></div><div>My original proposal w=
as to warn when type juggling NAN, as this is unexpected&nbsp;</div><div=
>behaviour, and this was discussed on the mailing list.&nbsp; Then, just=
 this</div><div>Saturday, Claude pointed out that INF also has this prob=
lem (casting INF to int</div><div>produces zero, which is even more clea=
rly a problem).&nbsp; After confirming this</div><div>and thinking about=
 it, I wanted to modify my existing wording to account for</div><div>thi=
s edge case; doing so would have resulted in very convoluted language,</=
div><div>however, so instead I added the new proposal to make it clear t=
his is a closely</div><div>related but even more narrow change.</div><di=
v><br></div><div>This is the highest possible bar that I have set: addin=
g the new edge case as a</div><div>secondary vote would have been comple=
tely justified, and this would require a</div><div>smaller majority of a=
 vote.&nbsp; If I was worried about a procedural spanner in the</div><di=
v>works, I could have just shoehorned this minor change into the existin=
g text</div><div>and this would also have been completely justified.&nbs=
p; I made the changes in the</div><div>clearest possible way for the ben=
efit of people reading the wiki.</div><div><br></div><div>I will now ope=
n the vote as-is, anyone is free to convince people to simply</div><div>=
vote against it, or do the most procedurally correct thing of starting a=
n RFC</div><div>to render it void after the fact (regardless of the outc=
ome of this vote).</div><div><br></div><div>Regarding the suggestion to =
simply kick the can down the road to the next</div><div>version: we do n=
ot know if the next version will be 9.0, which if the same</div><div>req=
uest is made about deprecation as 8.0 had, this would mean the warning f=
or</div><div>this could not be introduced until 9.1, and then it could o=
nly be upgraded to</div><div>an error by PHP 10.0. This seems like a dis=
proportionate amount of extra work</div><div>for such a minor change.</d=
iv><div><br></div><div>I agree it is important for internals to voice th=
eir concerns.&nbsp; I am simply</div><div>upset that a very minor *proce=
dural* disagreement is once again incentivising</div><div>me to smuggle =
in common-sense changes through procedural back doors rather than</div><=
div>write my proposals clearly.&nbsp; This seems like a clearly positive=
 and minor</div><div>change; anyone who disagrees on *technical* grounds=
 can vote no, and if the</div><div>procedural issue really is so importa=
nt, there is a recourse available for</div><div>this.&nbsp; Having to fi=
ght these kinds of battles over my work to improve the</div><div>languag=
e is needlessly taxing, and this too is a form of unhealthy environment.=
</div><div><br></div><div><br></div><div>Best regards,</div><div><br></d=
iv><div>Gina P. Banyard<br></div></blockquote><div><br></div><div>I am n=
ot sure that (int)"INF" or (int)"NAN" is misbehaving. (int)"Password" al=
so produces `0`, and these are strings. If we had the time to discuss it=
 properly, I would argue that simply warning when casting a string to in=
t is the most sensible thing, just like we get an error when coercing a =
string to int, which is more consistent across the language than just sp=
ecial casing some strings.</div><div><br></div><div id=3D"sig121229152">=
=E2=80=94 Rob</div></body></html>
--3905c80bfbfa48e1903e1a1c0ddb2b0d--