Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130225
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PHP-DEV] [RFC] Exempt input type and value validation from BC
 Break policy
Date: Mon, 2 Mar 2026 20:51:05 +0100
References: <Sm1GZb5hgsnp0GsxSRFcsRA5FiZoHJMi9368TSt4Qb8Qr61aFDSGxQMP9fpj58uMVwPgynuve8bplPhSZhR4HSnfHUCpoBqInTHWjd-uUyA=@gpb.moe>
 <FAEFF35B-D1DB-4C1C-8F92-213EECDD6230@cschneid.com>
 <b431a150-a4d2-42ee-b918-d9ad38fa7719@bastelstu.be>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <b431a150-a4d2-42ee-b918-d9ad38fa7719@bastelstu.be>
Message-ID: <650FCF24-CDBD-4F37-BA50-6D691EE3E3E1@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

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 changing the behaviour?
>=20
> =E2=80=9CNot passing invalid values=E2=80=9D is perfectly backwards =
compatible. 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 in 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 =
stuff on hosting services.
- As a hoster I'd rather have a phase where my customers get warnings =
instead of errors, creates less emergency support load.

> 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 =
warning and notice to an Exception.

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 =
probably 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 =
behavior. 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.

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 =
behaving in a completely deterministic and valid way.

> Going through an E_WARNING would add maintainer busywork and =
complicate 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 =
twice 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 more 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 =
sophisticated..
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 =
targets the long tail of PHP code / developers out there not using =
full-fledged frameworks and dev environments or running legacy software =
on hosting services.

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 =
developers.

Regards,
- Chris