Everything

php

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

php.internals

LamentXU

222 days ago

Hi internals,

I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'

Wiki page: https://wiki.php.net/rfc/trim_form_feed
discussion thread: https://news-web.php.net/php.internals/129706
date to end: 2026/2/6 15:30:00 UTC

Thank you in advance for your participation.

Cheers,
Weilin Du

Derick Rethans

222 days ago

On 22 January 2026 14:38:29 GMT, LamentXU <lamentxu@163.com> wrote:

>Hi internals,
>
>
>I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
>
>
>Wiki page: https://wiki.php.net/rfc/trim_form_feed
>discussion thread: https://news-web.php.net/php.internals/129706
>date to end: 2026/2/6 15:30:00 UTC
>
>Thank you in advance for your participation.

It shows "PHP 8.5" as target version in the RFC. That's not possible, as it had already been released.

cheers
Derick

LamentXU

214 days ago

Oops my bad, I didn't realize the new version is released. I am convinced by Ben that the feature should be in 9.0 since this is technically a BC break.

Hmmm, so in this case I am not that sure whether I should directly reopen the vote or put in 'under discussion' again and been through another cool down period.

Cheers,
Weilin Du
----- Original Message -----
From: "Derick Rethans" <derick@php.net>
To: LamentXU <lamentxu@163.com>, "internals@lists.php.net" <internals@lists.php.net>
Sent: Thu, 22 Jan 2026 15:37:35 +0000
Subject: Re: [PHP-DEV] [Vote] Add form feed as a whitespace character in trim, ltrim and rtrim

On 22 January 2026 14:38:29 GMT, LamentXU <lamentxu@163.com> wrote:
>Hi internals,
>
>
>I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
>
>
>Wiki page: https://wiki.php.net/rfc/trim_form_feed
>discussion thread: https://news-web.php.net/php.internals/129706
>date to end: 2026/2/6 15:30:00 UTC
>
>Thank you in advance for your participation.

It shows "PHP 8.5" as target version in the RFC. That's not possible, as it had already been released.

cheers
Derick

LamentXU

214 days ago

Just got the newest email. I will reset the vote again and change the version to 9.0. Thank you.


Cheers,
Weilin Du

Ben Ramsey

214 days ago

On 1/22/26 09:38, LamentXU wrote:

> Hi internals,
>
>
> I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
>
>
> Wiki page: https://wiki.php.net/rfc/trim_form_feed
> discussion thread: https://news-web.php.net/php.internals/129706
> date to end: 2026/2/6 15:30:00 UTC
>
>
> Thank you in advance for your participation.
>
>
> Cheers,
> Weilin Du
>

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.

Cheers,
Ben

Ben Ramsey

214 days ago

On 1/29/26 19:37, Ben Ramsey wrote:

> On 1/22/26 09:38, LamentXU wrote:
>> Hi internals,
>>
>>
>> I am posting this to announce the start of the voting process of the
>> RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
>>
>>
>> Wiki page: https://wiki.php.net/rfc/trim_form_feed
>> discussion thread: https://news-web.php.net/php.internals/129706
>> date to end: 2026/2/6 15:30:00 UTC
>>
>>
>> Thank you in advance for your participation.
>>
>>
>> Cheers,
>> Weilin Du
>>
>
>
> 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.
>
> Cheers,
> Ben
>
>

It looks like you changed the proposed PHP version from 8.6 to 8.5 on
the same day you opened voting.[^1] IMO, this was at least a minor
change (according to our Feature Proposals policy), which requires
notifying the mailing list of the change and should have triggered a
7-day cool down before voting could begin.[^2]

I appreciate the work you've put into this, and I agree with the need
for this change, but I'm a little worried those who voted "yes" might
not have noticed the proposed version change on the RFC from PHP 8.6 to
PHP 8.5.

Cheers,
Ben


[1]:
https://wiki.php.net/rfc/trim_form_feed?do=diff&rev2%5B0%5D=1768834282&rev2%5B1%5D=1769092319&difftype=sidebyside
[2]:
https://github.com/php/policies/blob/main/feature-proposals.rst#cooldown-period

Tim Düsterhus

210 days ago

Hi

Am 2026-01-30 01:51, schrieb Ben Ramsey:

> It looks like you changed the proposed PHP version from 8.6 to 8.5 on
> the same day you opened voting.[^1] IMO, this was at least a minor
> change (according to our Feature Proposals policy), which requires
> notifying the mailing list of the change and should have triggered a
> 7-day cool down before voting could begin.[^2]
>
> I appreciate the work you've put into this, and I agree with the need
> for this change, but I'm a little worried those who voted "yes" might
> not have noticed the proposed version change on the RFC from PHP 8.6 to
> PHP 8.5.

From a policy PoV this is interesting, because the incorrect version was
noticed fairly quickly, but it was not noticed that the RFC recently
changed. When that was noticed, the 7-day window to cancel the vote
already expired, meaning there are now two conflicting policy
violations. But since this issue was pointed out early on, I ultimately
agree with the canceling of the vote.

Best regards
Tim Düsterhus

Tim Düsterhus

210 days ago

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

Ben Ramsey

209 days ago

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

Larry Garfield

209 days ago

On Tue, Feb 3, 2026, at 7:16 PM, Ben Ramsey wrote:

> 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

Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.

Majors exist for a reason.

--Larry Garfield

Gina P. Banyard

209 days ago

On Wednesday, 4 February 2026 at 14:42, Larry Garfield <larry@garfieldtech.com> wrote:

>
> Where as I would, because we catch flack every version for how many "small" BC breaks we have. It hinders people's ability to upgrade and generates bad PR for PHP routinely.
>
> Majors exist for a reason.

PHP does not follow SemVer.
Minor BC breaks are accepted via our policy.
And as Tim said, waiting multiple years for a consistency fix (which frankly in my opinion this is more a bug fix) is completely ludicrous.

But as usual none of this would be a problem if we didn't bundle 14 000 extensions and the standard library being so massive and shoved into a single extension.
As then, the core language and extension APIs could evolve at different paces, and thus following SemVer would at least be a potential consideration.


Best regards,

Gina P. Banyard

Volker Dusch

209 days ago

On Wed, Feb 4, 2026 at 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote:

>
> Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.
>
> Majors exist for a reason.
>

That claim is completely unsubstantiated, doesn't reflect my
experienced and researched reality, and feels quite off-topic, given
PHP very much allows for this.

--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint

Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127

Larry Garfield

208 days ago

On Wed, Feb 4, 2026, at 11:09 AM, Volker Dusch wrote:

> On Wed, Feb 4, 2026 at 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote:
>>
>> Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.
>>
>> Majors exist for a reason.
>>
>
> That claim is completely unsubstantiated, doesn't reflect my
> experienced and researched reality, and feels quite off-topic, given
> PHP very much allows for this.

Citation:
https://24daysindecember.net/2022/12/06/evolving-php/

Nikita's proposal for "Editions":
https://externals.io/message/106453#106454

Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.

I have responded to these issues myself in the past as well, defending PHP's approach:

https://www.garfieldtech.com/blog/upgrading-php-upgrades

But when we can ensure that upgrades are smooth and uneventful, we should.

--Larry Garfield

Gina P. Banyard

208 days ago

On Thursday, 5 February 2026 at 16:04, Larry Garfield <larry@garfieldtech.com> wrote:

> Nikita's proposal for "Editions":
> https://externals.io/message/106453#106454

Nikita's edition proposal explicitly moved out of scope library changes, which ext/standard is. [1]

> But when we can ensure that upgrades are smooth and uneventful, we should.

Every single minor release, we implement bug fixes that we deem too disruptive to do in a stable branch.
Sometimes due to behavioural changes, which I will reiterate this very much feels like a bug fix to me.

Moreover, in the current state of the project it is extremely unreasonable to demand that any minor thing be pushed back who knows how many years.
We didn't even properly handle removing all deprecation in PHP 8.0 and so have been carrying these deprecations for another 5 years.

You could not expect from the core team to spend a year + just converting resources to opaque objects, that's why it was done in stages in multiple minor releases.
(and once again this wouldn't have been an issue if those extensions didn't live in the php-src repo and weren't tied to PHP's release process.)
And we have lost *multiple* contributors to core because they were explicitly told the thing they were working on they should have submitted 5-6 years earlier or should wait until PHP 9.
Forcing everything to wait until the next major is a sure fire way of demotivating new people from working on the language.

Recently, discussion about fixing minor things in PHP seem to always get sidetracked by people who are not actively involved in the maintenance of PHP questioning every single decision even if those processes have been established for years.
Sometimes those are undocumented, but event after clarifying some, there is still constant questioning.
This makes working on PHP a chore and wastes a lot of people's time (and money) re-iterating existing practice, while holding the evolution of the language back.
Given how we discuss these things these days, I don't think I would have started to contribute to PHP if I started getting involved in 2025.

Best regards,

Gina P. Banyard


[1] https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md#scope-and-eligible-changes

Volker Dusch

208 days ago

On Thu, Feb 5, 2026 at 5:02 PM Larry Garfield <larry@garfieldtech.com> wrote:

> Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.

From what I'm seeing, having to support property hooks and pipes as
valid syntax was more of a ""BC"" impact for PHP 8.x than all bug
fixes we shipped since 8.0.0 combined.

PHP has rules on what can go into a release to make this predictable,
and it's clear for tool authors what we consider BC and what not.

>
> But when we can ensure that upgrades are smooth and uneventful, we should.
>

We do. I don't think your presentation of how PHP is developed and
evolves is helping discuss this, imho, absolutely compliant and
sensible RFC (might not even needed to be an RFC, but that's off-topic
as well).

I'd rather not have this policy discussion again in 2026, but either
way, this is the wrong place.

Regards,
Volker

--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint

Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127

Unnamed Person

206 days ago

On 5-2-2026 17:00, Larry Garfield wrote:

> On Wed, Feb 4, 2026, at 11:09 AM, Volker Dusch wrote:
>> On Wed, Feb 4, 2026 at 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote:
>>> Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.
>>>
>>> Majors exist for a reason.
>>>
>> That claim is completely unsubstantiated, doesn't reflect my
>> experienced and researched reality, and feels quite off-topic, given
>> PHP very much allows for this.
> Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.

My ears were burning. And yes, "minor" BC breaks can definitely be
hugely problematic, however, the "BC-break" proposed in this RFC - to me
- is not one in that category. Feels more like a bug-fix.

Derick Rethans

206 days ago

On 6 February 2026 23:58:17 GMT, Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> wrote:

>On 5-2-2026 17:00, Larry Garfield wrote:
>> On Wed, Feb 4, 2026, at 11:09 AM, Volker Dusch wrote:
>>> On Wed, Feb 4, 2026 at 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote:
>>>> Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.
>>>>
>>>> Majors exist for a reason.
>>>>
>>> That claim is completely unsubstantiated, doesn't reflect my
>>> experienced and researched reality, and feels quite off-topic, given
>>> PHP very much allows for this.
>> Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
>My ears were burning. And yes, "minor" BC breaks can definitely be hugely problematic, however, the "BC-break" proposed in this RFC - to me - is not one in that category. Feels more like a bug-fix.

This is what I've been thinking all along, this is a bug fix.

I wasn't quite sure whether this was considered as anything else, and think a lot of time was wasted in this process. Process can be good when it is appropriate, but that line wasn't reached for this bug fix in my opinion.

cheers
Derick

Volker Dusch

209 days ago

On Fri, Jan 30, 2026 at 1:39 AM Ben Ramsey <ramsey@php.net> wrote:

>
> 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.
>
> Cheers,
> Ben
>
>

I would urge you to reconsider. Pushing all bug fixes with extremely
minor BC implications into a single release that happens every 5-7
years will create problems with adoption.

This fix should, imho, very clearly go into 8.6.

Every minor ships with a BC list. E.g.
https://www.php.net/manual/en/migration85.incompatible.php and there
is nothing I can think of that is more minor than this change (maybe
except adding deprecations).

Kind regards,
Volker

--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint

Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127

Ben Ramsey

209 days ago

On 2/4/26 11:16, Volker Dusch wrote:

> On Fri, Jan 30, 2026 at 1:39 AM Ben Ramsey <ramsey@php.net> wrote:
>>
>> 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.
>>
>> Cheers,
>> Ben
>>
>>
>
> I would urge you to reconsider. Pushing all bug fixes with extremely
> minor BC implications into a single release that happens every 5-7
> years will create problems with adoption.
>
> This fix should, imho, very clearly go into 8.6.
>
> Every minor ships with a BC list. E.g.
> https://www.php.net/manual/en/migration85.incompatible.php and there
> is nothing I can think of that is more minor than this change (maybe
> except adding deprecations).
>
> Kind regards,
> Volker
>

FWIW, I didn't call for the voting to be stopped. I pointed out the RFC
was changed on the day voting began to target PHP 8.5 (from 8.6) without
notifying the list, and I was worried those who voted might not have
noticed the change.

Cheers,
Ben