[UNDER DISCUSSION][RFC] grapheme_strrev function

php.internals

youkidearitai

228 days ago
Hi, internals. I creating a new function for strrev for grapheme cluster unit. grapheme_strrev function. My investigate, Sometime found mb_strrev function for userland. However, I think create a grapheme cluster unit for strrev function. Because multi code point in human language and emoji. I created an RFC and Pull Request. Feel free to comment. https://wiki.php.net/rfc/grapheme_strrev https://github.com/php/php-src/pull/20949 Regards Yuya
-- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Tim Düsterhus

225 days ago
Hi On 1/16/26 08:20, youkidearitai wrote:
> I creating a new function for strrev for grapheme cluster unit. > grapheme_strrev function. > > My investigate, Sometime found mb_strrev function for userland. > However, I think create a grapheme cluster unit for strrev function. > Because multi code point in human language and emoji. > > I created an RFC and Pull Request. > Feel free to comment. > https://wiki.php.net/rfc/grapheme_strrev > https://github.com/php/php-src/pull/20949
Thank you for your RFC. Aligning the feature set of the grapheme functions with those of mbstring and the bytestring-based functions definitely makes sense to me. I am thus in favor of the RFC. For the RFC document itself: You did not fill in the "RFC Impact" section. I think it can just be "None" for each of them. The only impact is the conflict with a possibly existing function. You already mentioned that in the breaking changes section. Adding new functions doesn't have any relevant impact on tools or IDEs, this is something that regularly happens. For Future Scope it can probably also be "None"? Even if you plan to add more grapheme functions, they are independent of grapheme_strrev. In the References section, please add a link to the mailing list archives of the discussion. This makes it easy for folks to find the discussion in the future. The correct link is: https://news-web.php.net/php.internals/129765 Best regards Tim Düsterhus

youkidearitai

224 days ago
2026年1月20日(火) 3:34 Tim Düsterhus <tim@bastelstu.be>:
> > Hi > > On 1/16/26 08:20, youkidearitai wrote: > > I creating a new function for strrev for grapheme cluster unit. > > grapheme_strrev function. > > > > My investigate, Sometime found mb_strrev function for userland. > > However, I think create a grapheme cluster unit for strrev function. > > Because multi code point in human language and emoji. > > > > I created an RFC and Pull Request. > > Feel free to comment. > > https://wiki.php.net/rfc/grapheme_strrev > > https://github.com/php/php-src/pull/20949 > > Thank you for your RFC. Aligning the feature set of the grapheme > functions with those of mbstring and the bytestring-based functions > definitely makes sense to me. I am thus in favor of the RFC. > > For the RFC document itself: > > You did not fill in the "RFC Impact" section. I think it can just be > "None" for each of them. The only impact is the conflict with a possibly > existing function. You already mentioned that in the breaking changes > section. Adding new functions doesn't have any relevant impact on tools > or IDEs, this is something that regularly happens. > > For Future Scope it can probably also be "None"? Even if you plan to add > more grapheme functions, they are independent of grapheme_strrev. > > In the References section, please add a link to the mailing list > archives of the discussion. This makes it easy for folks to find the > discussion in the future. The correct link is: > https://news-web.php.net/php.internals/129765 > > Best regards > Tim Düsterhus
Hi, Tim Thank you for your feedback! I'm glad your agree. And apply from your feedback. Regards Yuya
-- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Tim Düsterhus

223 days ago
Hi Am 2026-01-20 09:14, schrieb youkidearitai:
> Thank you for your feedback! > I'm glad your agree. > And apply from your feedback.
Thank you. I don't have any more feedback. I'm happy to vote “Yes” when the vote starts. Before starting the vote: Please keep in mind the new cooldown period after RFC changes. It is explained here: https://github.com/php/policies/blob/main/feature-proposals.rst#cooldown-period. It is probably best to treat these changes as a "Major change". This means the cooldown ends on 2026-02-03 when no other changes are made. After the cooldown ends when you think the RFC is ready, you must send an announcement of the vote. Two days later you may open the vote as you already know. Best regards Tim Düsterhus

youkidearitai

210 days ago
2026年1月22日(木) 0:31 Tim Düsterhus <tim@bastelstu.be>:
> > Hi > > Am 2026-01-20 09:14, schrieb youkidearitai: > > Thank you for your feedback! > > I'm glad your agree. > > And apply from your feedback. > > Thank you. I don't have any more feedback. I'm happy to vote “Yes” when > the vote starts. > > Before starting the vote: Please keep in mind the new cooldown period > after RFC changes. It is explained here: > https://github.com/php/policies/blob/main/feature-proposals.rst#cooldown-period. > It is probably best to treat these changes as a "Major change". This > means the cooldown ends on 2026-02-03 when no other changes are made. > After the cooldown ends when you think the RFC is ready, you must send > an announcement of the vote. Two days later you may open the vote as you > already know. > > Best regards > Tim Düsterhus
Hi, Tim Thank you very much. Hi, Internals If doesn't any concerns, I would like to leave the "cooldown" phase. And I would like to go to "Vote" phase in 2026-02-06 00:00:00 UTC. Best Regards Yuya.
-- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Tim Düsterhus

210 days ago
Hi Am 2026-02-03 08:34, schrieb youkidearitai:
> If doesn't any concerns, I would like to leave the "cooldown" phase. > And I would like to go to "Vote" phase in 2026-02-06 00:00:00 UTC.
Thank you. As I said I am happy with the RFC now. Starting the vote on the suggested date makes sense to me! Best regards Tim Düsterhus