Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130278
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <gpSgetGUf_ezKIy9oE-9KdL2GvX21uWTZBl2LnVI7a0LXjBLONNcEk1dCNoMoPBXPx_FO00cITiqQ9yqoc0AVQg6i-de1PwZbNvwLUEUals=@gpb.moe>
Date: Mon, 9 Mar 2026 13:52:47 +0000
Message-ID: <CAGBsUrd=GDPznp2fqM6=Rb3GbhDh8apmSSa-s3NooOaJ=NG+kA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Exempt input type and value validation from BC
 Break policy
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: Christian Schneider <cschneid@cschneid.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tekiela246@gmail.com (Kamil Tekiela)

On Mon, 9 Mar 2026 at 13:37, Gina P. Banyard <internals@gpb.moe> wrote:
>
> On Monday, 2 March 2026 at 19:54, Christian Schneider <cschneid@cschneid.=
com> 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 cas=
es) go through an E_WARNING phase to allow a time window to fix code before=
 changing the behaviour?
> > >
> > > =E2=80=9CNot passing invalid values=E2=80=9D is perfectly backwards c=
ompatible. Folks can just fix their code before upgrading their production =
deployment to the new PHP version, e.g. by trying out the new PHP version i=
n a staging system or running CI for both the old and new PHP version.
> >
> > - Not everybody has access to a staging system, e.g. people running stu=
ff on hosting services.
> > - As a hoster I'd rather have a phase where my customers get warnings i=
nstead of errors, creates less emergency support load.
> >
> > > In practice an E_WARNING is no less breaking than going straight to a=
n Error, because:
> > > 1. The common frameworks include error handlers that just convert any=
 warning and notice to an Exception.
> >
> > So in that sense there is also no advantage to NOT having a warning pha=
se for those people.
> > But people treating E_WARNING different from Exceptions (which is proba=
bly the exact people whose code breaks with an immediate Exception) do have=
 a time window to fix things.
> >
> > > 2. The code is already broken, because it relies on unspecified behav=
ior. The error would just making the user aware that the code is very likel=
y not doing what it appears to be doing based on the input values passed to=
 a function.
> >
> > It can easily do something valid and ignore the extra bits (pun kind of=
 intended), see
> >       mkdir("foo", 070777);
> > which passes extra bits with are ignored but the application was behavi=
ng in a completely deterministic and valid way.
> >
> > > Going through an E_WARNING would add maintainer busywork and complica=
te the php-src codebase for no real gain.
> >
> > We've been over this before:
> > If people *really* feel that the additional burden to change the code t=
wice then I'd be happy to volunteer providing a small helper function/macro=
 to generate an E_WARNING and either (the more aggressive approach) switch =
to an exception once a certain PHP version is reached or  (probably the mor=
e flexible way) issue a compile time warning/error informing the maintainer=
 to switch the warning to an Exception.
> > The most simplistic version of this is a FIXME comment annotated with a=
 version number. Easy to grep, easy to trigger automatic alerts about once =
the specified version is reached, but it can also be something more sophist=
icated..
> > One way or the other could also be integrated into the CI/CD system.
> >
> > Our main disagreement is about the "no real gain" part as it IMHO targe=
ts the long tail of PHP code / developers out there not using full-fledged =
frameworks and dev environments or running legacy software on hosting servi=
ces.
> >
> > I am very much in favor of making things easy for the code developers b=
ut I am of the strong believe that it can be done in a good way for develop=
ers.
>
> I don't see how going through an E_WARNING phase is helpful, rather I see=
 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 nonsensical =
value?
> AFAIK every time a warning got introduced it followed the first approach,=
 so 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 solv=
ed the concern in the slightest.
> As it may be a warning for one PHP version and in the next PHP version th=
e extension supports a new flag which removes the warning for that value, l=
eading back to a silent BC break if the warning wasn't addressed.
>
> Another technical aspect is that warnings allows userland code to run and=
 change the state of the VM and extension in unexpected way (we have countl=
ess fuzzying reports about this) an issue that does not exist with Exceptio=
ns.
>
> Then comes the topic about how long should it be a warning? Until the nex=
t major? A single release cycle? I don't want warning promotion to become t=
he same exhausting discussion that deprecation duration already is.
>
> I have no idea how you handle hosting, but when I used shared hosting in =
the past I would never have anyone tell me that my code was producing warni=
ngs or notices.
> And even the one website I manage for someone which is on OVH shared host=
ing I can still select a PHP version (heck even downgrading to 5.4 for some=
 reason).
> So I'm struggling to see how for the average end user this is impacting t=
hem?
> And if you do just bump the PHP version for them, I'm not sure what's the=
 difference between having an Error immediately or producing warnings for X=
 years before throwing an Error and breaking
>
> Best regards,
>
> Gina P. Banyard

I am in favour of exempting the validation errors from requiring RFCs,
and as Gina, I do not believe that warnings are useful. I don't like
that warnings even exist in the PHP language. I can see the case that
you don't want to break a running application by upgrading the PHP
version, but it can happen regardless. Minor PHP releases can contain
minor breaking changes and each time someone upgrades PHP, they should
run their test suite and verify that the application still works the
same as before. Whether we introduce a Warning or ValueError, it will
be caught during the upgrade process and fixed. It may even help avoid
nasty bugs if the application stops on invalid input; something which
could go unnoticed if it were only a warning.

I am, however, concerned about one thing. If we don't require RFCs
there may be situations when a contentious validation is introduced.
For example, many validations can be implemented in such a way that
they don't cause additional performance loss, but let's say someone
decides that validating the value provides more benefit than the
performance cost. Without RFC, the community cannot share their
feedback, and one person's opinion wins. But if the function is used
with the correct values 99.99% of the time and it's used in the hot
code, the performance cost isn't worth catching the accidental invalid
value.