Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130389
Date: Wed, 18 Mar 2026 12:20:18 +0000
To: Kamil Tekiela <tekiela246@gmail.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: <kW_qTTRkKOX5enL0VLn02wEKXPR_eHe7TfkBPEy1GW2H5O3RDJ6Qcuz9Z9i2PiQmeldT1TO-v1Hk5C8NiEr_hcG-Ff5VvOhnaeuhWjn841k=@gpb.moe>
In-Reply-To: <CAGBsUrd=GDPznp2fqM6=Rb3GbhDh8apmSSa-s3NooOaJ=NG+kA@mail.gmail.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> <gpSgetGUf_ezKIy9oE-9KdL2GvX21uWTZBl2LnVI7a0LXjBLONNcEk1dCNoMoPBXPx_FO00cITiqQ9yqoc0AVQg6i-de1PwZbNvwLUEUals=@gpb.moe> <CAGBsUrd=GDPznp2fqM6=Rb3GbhDh8apmSSa-s3NooOaJ=NG+kA@mail.gmail.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, 9 March 2026 at 13:53, Kamil Tekiela <tekiela246@gmail.com> wrot=
e:

> [...]
>=20
> 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.

I don't think this concern is warranted in practice for at least 2 reasons:

- The majority of those functions are not going to be purely computational =
functions and are tied to some I/O operation
- These input checking guards should be wrapped in UNEXPECTED() hinting to =
the CPU that they should optimize for this branch not to be taken


Best regards,

Gina P. Banyard