Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130279
Content-Type: text/plain;
	charset=us-ascii
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, 9 Mar 2026 16:49:41 +0100
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>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <gpSgetGUf_ezKIy9oE-9KdL2GvX21uWTZBl2LnVI7a0LXjBLONNcEk1dCNoMoPBXPx_FO00cITiqQ9yqoc0AVQg6i-de1PwZbNvwLUEUals=@gpb.moe>
Message-ID: <E6AB3BE0-0F57-454A-9A35-683153037A61@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

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 =
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?

in all the previous cases where we deprecated things we continued to =
leave the behaviour unchanged apart from issuing the warning.

> 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.

Replace E_WARNING in your phrasing with E_DEPRECATED and your statement =
becomes obviously false.
If that's the differentiator for you then I'm happy to have an =
E_DEPRECATED phase before throwing a ValueError exception.

> 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, leading back to a silent BC break if the warning wasn't =
addressed.

Nothing can protect you from old code using a new flag by accident. =
Imagine 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.

> 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.

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 =
why I'm advocating the IMHO tested and proven solution we are using for =
deprecations.

> 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 =
warnings or notices.
> And even the one website I manage for someone which is on OVH shared =
hosting 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 them?

I'm supporting applications running on hosters where they bump the =
minimal supported version quite often.
"Works for me" is hardly ever a strong argument...

Regards,
- Chris