PHP RFC: Add Form Feed in Trim Functions

Version: 1.0
Date: 2025-12-28
Author: Weilin Du, lamentxu@163.com
Status: Under Discussion
Implementation: https://github.com/php/php-src/pull/20788

Introduction

The trim(), ltrim(), and rtrim() functions strip whitespace (or other characters) from the beginning and end of a string. When the second parameter ($characters) is omitted, these functions use a default set of characters.

Currently, this default set includes:

“ ” (ASCII 32 (0x20)), an ordinary space.
“\t” (ASCII 9 (0x09)), a tab.
“\n” (ASCII 10 (0x0A)), a new line (line feed).
“\r” (ASCII 13 (0x0D)), a carriage return.
“\0” (ASCII 0 (0x00)), the NUL-byte.
“\v” (ASCII 11 (0x0B)), a vertical tab.

Notably missing from this list is “\f” (ASCII 12 (0x0C)), the Form Feed character.

This RFC proposes adding “\f” to the default list of characters stripped by trim(), ltrim(), and rtrim().

Proposal

The proposal is to include the Form Feed character (\f / 0x0C) in the default character mask for trim(), ltrim(), and rtrim(). Most modern programming languages treat \f as whitespace in their trimming functions. Aligning PHP with this behavior reduces cognitive load for developers working in polyglot environments.

The Form Feed character is widely recognized as whitespace.

C Standard / POSIX: The isspace() function in libc (which PHP relies on internally) defines \f as a whitespace character.
PHP Internals: Other PHP functions such as is_numeric() already treat \f as whitespace when parsing strings.
Python: str.strip() removes \f by default (defined in string.whitespace).
JavaScript: String.prototype.trim() removes \f (defined as White_Space in ECMA-262, see MDN Web Docs).
Rust: str::trim() removes \f (based on Unicode White_Space property, see std::primitive::str::trim).
Go: strings.TrimSpace() removes \f (see strings.TrimSpace).

Examples

<?php
 
// Current Behavior
$str = "\fHello World\f";
var_dump(trim($str));
// string(13) "\fHello World\f"
 
// Proposed Behavior
$str = "\fHello World\f";
var_dump(trim($str));
// string(11) "Hello World"
 
?>

Backward Incompatible Changes

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

Proposed PHP Version(s)

PHP 8.6

RFC Impact

To the Ecosystem

There are several impacts to the ecosystem (mostly minor impacts):

IDEs and Language Servers: These tools will need to update their documentation (tooltips) for trim, ltrim, and rtrim to include \f in the list of default stripped characters.
Static Analyzers: These tools may need to update their internal return type inference logic. For example, trim(“\f”) currently results in a non-empty string, but under this proposal, it will result in an empty string. Updating their internal stubs will ensure accurate analysis.
Polyfills: Libraries that provide polyfills for string functions might need to be aware of this change, although polyfilling a change to a default parameter value in a core function is generally not done for minor versions.

To Existing Extensions

Existing extensions should not require recompilation.

To SAPIs

There is no specific impact on any SAPI (CLI, FPM, Apache, etc.). The change is limited to the string manipulation logic within the standard library.

Open Issues

Currently no open issues ongoing.

Future Scope

This RFC only focus on php function trim, ltrim and rtrim but not on other trimming functions implemented in php (such as in php filters).

Also, in the future there may be a new discussion about removing the NULL character (ASCII 0) from the default list of characters stripped by trim, ltrim and rtrim in a separated RFC.

Voting Choices

The voting will start after the cool-down period (expected 3 weeks, at Sat 18th Jan 2026 if no new issue(s) is raised).

Primary Vote requiring a 2/3 majority to accept the RFC:

Add form feed in trim, ltrim and rtrim default character mask as outlined in the RFC?
Real name	Yes	No	Abstain
Final result:	0	0	0
This poll has been closed.

Patches and Tests

Pull Request: GH-20788
Issue: GH-20783

Implementation

The RFC hasn't been accepted yet.

References

* Internal discussion

Rejected Features

None for now.

Changelog

2025/12/29: Initial version. 2025/12/29: Change typos and expressions, also title.