Re: [RFC] grapheme_str_pad()

From: 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

« previous php.internals (#133000) next »