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)
Hi
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
2026年1月20日(火) 3:34 Tim Düsterhus tim@bastelstu.be:
Hi
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/20949Thank 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/129765Best 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)
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
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)
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