Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128289
Date: Tue, 29 Jul 2025 09:01:40 +0000
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Warnings for PHP 8.5
Message-ID: <-EPNf2A21qLIrIyEvNmQxV_tNTa1IO5hU-LHGBhjfnVRB33qiwK3yhVV7AxDKSTDUl9ihRpapZLckSgnCn7t9RvUj9Jbtjnx1VLYqCQO6BI=@gpb.moe>
In-Reply-To: <CAPyj-LC03m4RmxBpZJSOdX3EStPRJu2BrRzE971kn-cyZLmHDw@mail.gmail.com>
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>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Monday, 28 July 2025 at 19:08, Ilija Tovilo <tovilo.ilija@gmail.com> wro=
te:

> Hi Gina
>=20
> On Mon, Jul 28, 2025 at 7:15=E2=80=AFPM Gina P. Banyard internals@gpb.moe=
 wrote:
>=20
> > I find it increasingly frustrating that trying to make PHP not be compl=
etely insane is met with resistance at every turn,
> > and I'm once more at the stage that I really should stop wasting my tim=
e 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

Hi Ilija,

Let's take a breath and review what's going on.

My original proposal was to warn when type juggling NAN, as this is unexpec=
ted=20
behaviour, and this was discussed on the mailing list.  Then, just this
Saturday, Claude pointed out that INF also has this problem (casting INF to=
 int
produces zero, which is even more clearly a problem).  After confirming thi=
s
and thinking about it, I wanted to modify my existing wording to account fo=
r
this edge case; doing so would have resulted in very convoluted language,
however, so instead I added the new proposal to make it clear this is a clo=
sely
related but even more narrow change.

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 require=
 a
smaller majority of a vote.  If I was worried about a procedural spanner in=
 the
works, I could have just shoehorned this minor change into the existing tex=
t
and this would also have been completely justified.  I made the changes in =
the
clearest possible way for the benefit of people reading the wiki.

I will now open the vote as-is, anyone is free to convince people to simply
vote against it, or do the most procedurally correct thing of starting an R=
FC
to render it void after the fact (regardless of the outcome of this vote).

Regarding the suggestion to simply kick the can down the road to the next
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 warning f=
or
this could not be introduced until 9.1, and then it could only be upgraded =
to
an error by PHP 10.0. This seems like a disproportionate amount of extra wo=
rk
for such a minor change.

I agree it is important for internals to voice their concerns.  I am simply
upset that a very minor *procedural* disagreement is once again incentivisi=
ng
me to smuggle in common-sense changes through procedural back doors rather =
than
write my proposals clearly.  This seems like a clearly positive and minor
change; anyone who disagrees on *technical* grounds can vote no, and if 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 environm=
ent.


Best regards,

Gina P. Banyard