Re: [Vote] Add form feed as a whitespace character in trim, ltrim and rtrim

On 2/3/26 08:18, Tim Düsterhus wrote:

Hi Am 2026-01-30 01:37, schrieb Ben Ramsey:

I've voted "no" on this RFC since the RFC says the proposed PHP version is PHP 8.5, which I interpret as meaning PHP 8.6, since 8.5 was released in November. Even if PHP 8.6 is the proposed version, I still think the target version should be PHP 9.0, since this is a BC break. I mentioned my concern about this being a BC break in the discussion thread. The RFC is also clear this is a BC break. It says:

This is a **backward incompatible change**. Scripts that rely on trim() *preserving* leading or trailing Form Feed characters will be affected.

I'm a little surprised by the number of folks who voted "yes" on this, despite it being very clear this is a BC break and PHP "Next" is the implied proposed version.

I however disagree that the target version of this RFC should be 9.0. It technically is a BC break, but so is almost anything else, including any bugfix. Our policy explicitly allows BC breaks in minor version, but gives some recommendations as to what BC breaks are acceptable: https:// github.com/php/policies/blob/6ff3612f7f60e9d91188d986cfb4ca84d0722732/ release-process.rst#minor-version-number While the proposed BC break would be a “silent” BC break, I believe it qualifies for the “case by case” exception, since: - It is unifying the behavior with other programming languages, including standards defining what “whitespace” means. - trim is well-understood in the community as “removing whitespace”. - Thus it not removing something that clearly is whitespace could be interpreted as a bug. - If users for some reason rely on form feed characters being preserved, I expect them to be well aware of their special requirement. - For those users, mitigating the break is possible with basic tooling, by simply searching the codebase for all occurences of trim( and then adjusting the calls to explicitly specify a list of characters to trim (or to replace them with a wrapper). For these reasons I don't think we should wait several years until PHP 9 to make the change. We're shipping more impactful breaking changes and bugfixes with every minor version. Best regards Tim Düsterhus

With this in mind, I'm still wary of the change, but I wouldn't vote against it if it targets PHP 8.6. Cheers, Ben

Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc