Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130008
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 04 Feb 2026 08:36:44 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <9310fbfc-a7bc-44df-beac-5a46d6b14f61@app.fastmail.com>
In-Reply-To: <20260204011605.D6E871A00BD@lists.php.net>
References: <4deea2df.a2a0.19be6247b75.Coremail.lamentxu@163.com>
 <20260130003750.5CA2A1A00BD@lists.php.net>
 <886205c77a8fdf08f4ddfb28b7605e51@bastelstu.be>
 <20260204011605.D6E871A00BD@lists.php.net>
Subject: Re: [PHP-DEV] [Vote] Add form feed as a whitespace character in trim, ltrim
 and rtrim
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Feb 3, 2026, at 7:16 PM, Ben Ramsey wrote:
> On 2/3/26 08:18, Tim D=C3=BCsterhus wrote:
>> Hi
>>=20
>> Am 2026-01-30 01:37, schrieb Ben Ramsey:
>>> I've voted "no" on this RFC since the RFC says the proposed PHP=20
>>> version is PHP 8.5, which I interpret as meaning PHP 8.6, since 8.5=20
>>> was released in November.
>>>
>>> Even if PHP 8.6 is the proposed version, I still think the target=20
>>> version should be PHP 9.0, since this is a BC break. I mentioned my=20
>>> 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 thi=
s,=20
>>> despite it being very clear this is a BC break and PHP "Next" is the=20
>>> implied proposed version.
>>=20
>> I however disagree that the target version of this RFC should be 9.0.
>>=20
>> It technically is a BC break, but so is almost anything else, includi=
ng=20
>> any bugfix. Our policy explicitly allows BC breaks in minor version, =
but=20
>> gives some recommendations as to what BC breaks are acceptable: https=
://=20
>> github.com/php/policies/blob/6ff3612f7f60e9d91188d986cfb4ca84d0722732=
/=20
>> release-process.rst#minor-version-number
>>=20
>> While the proposed BC break would be a =E2=80=9Csilent=E2=80=9D BC br=
eak, I believe it=20
>> qualifies for the =E2=80=9Ccase by case=E2=80=9D exception, since:
>>=20
>> - It is unifying the behavior with other programming languages,=20
>> including standards defining what =E2=80=9Cwhitespace=E2=80=9D means.
>> - trim is well-understood in the community as =E2=80=9Cremoving white=
space=E2=80=9D.
>> - Thus it not removing something that clearly is whitespace could be=20
>> interpreted as a bug.
>> - If users for some reason rely on form feed characters being preserv=
ed,=20
>> I expect them to be well aware of their special requirement.
>> - For those users, mitigating the break is possible with basic toolin=
g,=20
>> by simply searching the codebase for all occurences of `trim(` and th=
en=20
>> adjusting the calls to explicitly specify a list of characters to tri=
m=20
>> (or to replace them with a wrapper).
>>=20
>> For these reasons I don't think we should wait several years until PH=
P 9=20
>> to make the change. We're shipping more impactful breaking changes an=
d=20
>> bugfixes with every minor version.
>>=20
>> Best regards
>> Tim D=C3=BCsterhus
>
>
> With this in mind, I'm still wary of the change, but I wouldn't vote=20
> against it if it targets PHP 8.6.
>
> Cheers,
> Ben


Where as I would, because we catch flack every version for how many "sma=
ll" BC breaks we have.  It hinders people's ability to upgrade and gener=
ates bad PR for PHP routinely.

Majors exist for a reason.

--Larry Garfield