Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130277
Date: Mon, 09 Mar 2026 13:36:56 +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: <gpSgetGUf_ezKIy9oE-9KdL2GvX21uWTZBl2LnVI7a0LXjBLONNcEk1dCNoMoPBXPx_FO00cITiqQ9yqoc0AVQg6i-de1PwZbNvwLUEUals=@gpb.moe>
In-Reply-To: <650FCF24-CDBD-4F37-BA50-6D691EE3E3E1@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>
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, 2 March 2026 at 19:54, Christian Schneider <cschneid@cschneid.co=
m> wrote:

> Am 02.03.2026 um 20:12 schrieb Tim D=C3=BCsterhus <tim@bastelstu.be>:
> > On 3/2/26 14:49, Christian Schneider wrote:
> >> Playing my favourite broken record:
> >> Can we please state that additions of Exceptions should (in most cases=
) go through an E_WARNING phase to allow a time window to fix code before c=
hanging the behaviour?
> >
> > =E2=80=9CNot passing invalid values=E2=80=9D is perfectly backwards com=
patible. Folks can just fix their code before upgrading their production de=
ployment to the new PHP version, e.g. by trying out the new PHP version in =
a staging system or running CI for both the old and new PHP version.
>=20
> - Not everybody has access to a staging system, e.g. people running stuff=
 on hosting services.
> - As a hoster I'd rather have a phase where my customers get warnings ins=
tead of errors, creates less emergency support load.
>=20
> > In practice an E_WARNING is no less breaking than going straight to an =
Error, because:
> > 1. The common frameworks include error handlers that just convert any w=
arning and notice to an Exception.
>=20
> So in that sense there is also no advantage to NOT having a warning phase=
 for those people.
> But people treating E_WARNING different from Exceptions (which is probabl=
y the exact people whose code breaks with an immediate Exception) do have a=
 time window to fix things.
>=20
> > 2. The code is already broken, because it relies on unspecified behavio=
r. The error would just making the user aware that the code is very likely =
not doing what it appears to be doing based on the input values passed to a=
 function.
>=20
> It can easily do something valid and ignore the extra bits (pun kind of i=
ntended), see
> =09mkdir("foo", 070777);
> which passes extra bits with are ignored but the application was behaving=
 in a completely deterministic and valid way.
>=20
> > Going through an E_WARNING would add maintainer busywork and complicate=
 the php-src codebase for no real gain.
>=20
> We've been over this before:
> If people *really* feel that the additional burden to change the code twi=
ce then I'd be happy to volunteer providing a small helper function/macro t=
o generate an E_WARNING and either (the more aggressive approach) switch to=
 an exception once a certain PHP version is reached or  (probably the more =
flexible way) issue a compile time warning/error informing the maintainer t=
o switch the warning to an Exception.
> The most simplistic version of this is a FIXME comment annotated with a v=
ersion number. Easy to grep, easy to trigger automatic alerts about once th=
e specified version is reached, but it can also be something more sophistic=
ated..
> One way or the other could also be integrated into the CI/CD system.
>=20
> Our main disagreement is about the "no real gain" part as it IMHO targets=
 the long tail of PHP code / developers out there not using full-fledged fr=
ameworks and dev environments or running legacy software on hosting service=
s.
>=20
> I am very much in favor of making things easy for the code developers but=
 I am of the strong believe that it can be done in a good way for developer=
s.

I don't see how going through an E_WARNING phase is helpful, rather I see i=
t 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 nonsensical va=
lue?
AFAIK every time a warning got introduced it followed the first approach, s=
o this doesn't seem to address the concern of giving developers more time.
However, if we do continue using the prior behaviour then we haven't solved=
 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, lea=
ding back to a silent BC break if the warning wasn't addressed.

Another technical aspect is that warnings allows userland code to run and c=
hange the state of the VM and extension in unexpected way (we have countles=
s fuzzying reports about this) an issue that does not exist with Exceptions=
.

Then comes the topic about how long should it be a warning? Until the next =
major? A single release cycle? I don't want warning promotion to become the=
 same exhausting discussion that deprecation duration already is.

I have no idea how you handle hosting, but when I used shared hosting in th=
e past I would never have anyone tell me that my code was producing warning=
s or notices.
And even the one website I manage for someone which is on OVH shared hostin=
g I can still select a PHP version (heck even downgrading to 5.4 for some r=
eason).
So I'm struggling to see how for the average end user this is impacting the=
m?
And if you do just bump the PHP version for them, I'm not sure what's the d=
ifference between having an Error immediately or producing warnings for X y=
ears before throwing an Error and breaking=20

Best regards,

Gina P. Banyard