Re: [RFC] Exempt input type and value validation from BC Break policy

On Monday, 9 March 2026 at 15:53, Christian Schneider <cschneid@cschneid.com> 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 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. 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 free code is getting phased out. These are fundamentally two different situations, thus I disagree that they should use a deprecation. > > > 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. 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 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... 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