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.
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.
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: php.internals: grapheme_strrev function
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.
> PHP: rfc:grapheme_strrev
> [RFC] Add grapheme_strrev function by youkidearitai · Pull Request #20949 · php/php-src · GitHub
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: php.internals: grapheme_strrev function
Best regards
Tim Düsterhus
Hi, Tim
Thank you for your feedback!
I'm glad your agree.
And apply from your feedback.
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: policies/feature-proposals.rst at main · php/policies · GitHub. 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.
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: policies/feature-proposals.rst at main · php/policies · GitHub.
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.