Re: [RFC] grapheme_str_pad()
| From: | Chris Abner Herrera Navarro | Date: | Wed, 04 Nov 2026 21:21:56 +0000 |
| Subject: | Re: [RFC] grapheme_str_pad() | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-133000@lists.php.net to get a copy of this message | ||
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