[PHP-DEV] [RFC] grapheme_str_pad()

Hi internals,

I'd like to start the discussion on a new RFC:

It proposes grapheme_str_pad(), the grapheme cluster counterpart of
str_pad() and mb_str_pad(), following the Future Scope of the mb_str_pad
RFC. The length is counted in grapheme clusters, so text in NFD, kana with
a combining dakuten, Indic scripts and emoji sequences are padded to the
same visible length as their single code point equivalents, and the padding
string is only cut on grapheme cluster boundaries.

Semantics and errors mirror mb_str_pad(). For ASCII input the result is
identical to str_pad().

Implementation: [RFC] Add grapheme_str_pad() function by ChrisAbner · Pull Request #25179 · php/php-src · GitHub

Thanks,
Chris Abner Herrera Navarro

Hi

On 2026-11-04 00:01, Chris Abner Herrera Navarro wrote:

I'd like to start the discussion on a new RFC:
PHP: rfc:grapheme_str_pad

[…]

Semantics and errors mirror mb_str_pad(). For ASCII input the result is
identical to str_pad().

Thank you for your RFC. Padding graphemes to a given length makes sense to me and the RFC clearly follows the established pattern of mirroring the string (bytestring) and mbstring (codepoint) functionality. I don't have any comments, the RFC includes exactly what I expected to see.

Best regards
Tim Düsterhus

2026年11月4日(水) 8:05 Chris Abner Herrera Navarro <chrisabner@hotmail.com>:

Hi internals,

I'd like to start the discussion on a new RFC:
PHP: rfc:grapheme_str_pad

It proposes grapheme_str_pad(), the grapheme cluster counterpart of
str_pad() and mb_str_pad(), following the Future Scope of the mb_str_pad
RFC. The length is counted in grapheme clusters, so text in NFD, kana with
a combining dakuten, Indic scripts and emoji sequences are padded to the
same visible length as their single code point equivalents, and the padding
string is only cut on grapheme cluster boundaries.

Semantics and errors mirror mb_str_pad(). For ASCII input the result is
identical to str_pad().

Implementation: [RFC] Add grapheme_str_pad() function by ChrisAbner · Pull Request #25179 · php/php-src · GitHub

Thanks,
Chris Abner Herrera Navarro

Hi

Thank you very much for your RFC.
It seems good to me.
And thank you for understanding grapheme functions.

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
-----------------------------

Hi Tim, Yuya,

It seems good to me.

Thank you both for taking a look.

I've updated the RFC to v0.2. Nothing changes in behaviour, these are
clarifications that came out of the review on the PR:

- $pad_string and $pad_type are only checked when padding is needed,
  like in mb_str_pad(). Otherwise $string is returned unchanged.
- The RFC said invalid UTF-8 is handled like in grapheme_strlen(), but
  grapheme_strlen() returns null there, not false. It now points to
  grapheme_substr() and grapheme_strpos() instead.
- The result has exactly $length grapheme clusters as long as the
  padding is made of complete clusters. A fragment like a lone
  combining mark can merge with the text next to it, the same way
  grapheme_strlen($a . $b) can be less than the sum of both lengths.

The implementation now also respects memory_limit for very large
results, and fills the padding faster.

Regards,
Chris Abner Herrera Navarro