Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130390
Date: Wed, 18 Mar 2026 12:28:03 +0000
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Exempt input type and value validation from BC Break policy
Message-ID: <URYttVXleFZ0MhfKCvFaSWl1LgbSC1NIV-eQyUUEg-EiKyKMJvr3wvcMr6fUsm9GyAjtOyi1LxDMpV8faJY2hYyhWmAZtug2O6LTzWPf2uw=@gpb.moe>
In-Reply-To: <E6AB3BE0-0F57-454A-9A35-683153037A61@cschneid.com>
References: <Sm1GZb5hgsnp0GsxSRFcsRA5FiZoHJMi9368TSt4Qb8Qr61aFDSGxQMP9fpj58uMVwPgynuve8bplPhSZhR4HSnfHUCpoBqInTHWjd-uUyA=@gpb.moe> <FAEFF35B-D1DB-4C1C-8F92-213EECDD6230@cschneid.com> <b431a150-a4d2-42ee-b918-d9ad38fa7719@bastelstu.be> <650FCF24-CDBD-4F37-BA50-6D691EE3E3E1@cschneid.com> <gpSgetGUf_ezKIy9oE-9KdL2GvX21uWTZBl2LnVI7a0LXjBLONNcEk1dCNoMoPBXPx_FO00cITiqQ9yqoc0AVQg6i-de1PwZbNvwLUEUals=@gpb.moe> <E6AB3BE0-0F57-454A-9A35-683153037A61@cschneid.com>
Feedback-ID: 96993444:user:proton
Precedence: list
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, 9 March 2026 at 15:53, Christian Schneider <cschneid@cschneid.co=
m> wrote:

> Am 09.03.2026 um 14:36 schrieb Gina P. Banyard <internals@gpb.moe>:
> > I don't see how going through an E_WARNING phase is helpful, rather I s=
ee it as detrimental.
> > Foremost, what is the behaviour of introducing a warning?
> > Do we exit early and return false?
> > Or do we just warn and continue to use a possible default or nonsensica=
l value?
>=20
> in all the previous cases where we deprecated things we continued to leav=
e the behaviour unchanged apart from issuing the warning.
>=20
> > AFAIK every time a warning got introduced it followed the first approac=
h, so this doesn't seem to address the concern of giving developers more ti=
me.
>=20
> Replace E_WARNING in your phrasing with E_DEPRECATED and your statement b=
ecomes obviously false.
> If that's the differentiator for you then I'm happy to have an E_DEPRECAT=
ED phase before throwing a ValueError exception.

These are not similar to deprecations. In these instances you have a silent=
 bug that is being suppressed, and you should be aware of it loud and clear=
.
A deprecation is a mechanism to indicate that previously *valid* and bug fr=
ee code is getting phased out.
These are fundamentally two different situations, thus I disagree that they=
 should use a deprecation.

>=20
> > However, if we do continue using the prior behaviour then we haven't so=
lved the concern in the slightest.
> > As it may be a warning for one PHP version and in the next PHP version =
the extension supports a new flag which removes the warning for that value,=
 leading back to a silent BC break if the warning wasn't addressed.
>=20
> Nothing can protect you from old code using a new flag by accident. Imagi=
ne someone skipping the version with the ValueError and going directly from=
 8.5 to the version with added flags. That's not the scope here.
>=20
> > Then comes the topic about how long should it be a warning? Until the n=
ext major? A single release cycle? I don't want warning promotion to become=
 the same exhausting discussion that deprecation duration already is.
>=20
> In my view it is *exactly* the same as deprecations and should be handled=
 as such.
> I'm on your side here that I don't want yet another process and that's wh=
y I'm advocating the IMHO tested and proven solution we are using for depre=
cations.
=20
As mentioned before I disagree that this is like a deprecation.

> > I have no idea how you handle hosting, but when I used shared hosting i=
n the past I would never have anyone tell me that my code was producing war=
nings or notices.
> > And even the one website I manage for someone which is on OVH shared ho=
sting I can still select a PHP version (heck even downgrading to 5.4 for so=
me reason).
> > So I'm struggling to see how for the average end user this is impacting=
 them?
>=20
> I'm supporting applications running on hosters where they bump the minima=
l supported version quite often.
> "Works for me" is hardly ever a strong argument...

This then seems to be self-inflicted problems from these specific hosters.
Unless they take the QA responsibility to ensure the migration works, just =
blindly upgrading PHP's version seems frankly irresponsible.


Best regards,

Gina P. Banyard