Hi,
I would like to open the discussion on my proposal to add new functions to process prefixes and suffixes
This is the link to the RFC: https://wiki.php.net/rfc/prefix_suffix_functions
This is the link to the proposed implementation: https://github.com/php/php-src/pull/20953
Thanks!!
Carlos
Hi
Am 2026-01-22 10:10, schrieb Barel:
I would like to open the discussion on my proposal to add new functions to
process prefixes and suffixesThis is the link to the RFC:
PHP: rfc:prefix_suffix_functions
Please don't forget to move it to the correct section in the overview at: PHP: rfc - and to add a link to the discussion thread archives to the “References” section. The “pre-RFC” thread is probably also to link there: php.internals: Proposal for functions that handle prefixes and suffixes
Best regards
Tim Düsterhus
Following a comment by Tim Düsterhus (thanks!) and another comment in the PR, I have inverted the order of the parameters in the ensure and remove functions, so that they follow the parameter order in related functions like str_contains() and str_starts_with()
Cheers
Carlos
On Thu, 22 Jan 2026 at 10:17, Tim Düsterhus <tim@bastelstu.be> wrote:
Hi
Am 2026-01-22 10:10, schrieb Barel:
I would like to open the discussion on my proposal to add new functions
to
process prefixes and suffixesThis is the link to the RFC:
https://wiki.php.net/rfc/prefix_suffix_functionsPlease don’t forget to move it to the correct section in the overview
at: https://wiki.php.net/rfc - and to add a link to the discussion
thread archives to the “References” section. The “pre-RFC” thread is
probably also to link there:
https://news-web.php.net/php.internals/129767Best regards
Tim Düsterhus
Hi
Am 2026-01-22 19:28, schrieb Barel:
Following a comment by Tim Düsterhus (thanks!) and another comment in the
PR, I have inverted the order of the parameters in the ensure and remove
functions, so that they follow the parameter order in related functions
like str_contains() and str_starts_with()
Thank you. I have given the RFC another look and have some polishing comments:
1. In the “Exact semantics (per function)” example it would probably be easier to understand if you would provide a userland implementation. Folks are already used to reading PHP and there is no ambiguity about the proposed behavior then. As a benefit, the implementation from the RFC would directly be usable as a polyfill, e.g. for use in GitHub - symfony/polyfill: PHP polyfills. The previous “array_find” RFC might be a good example here: PHP: rfc:array_find
2. In the “Backwards Incompatible Changes” section: Can you please perform some research for a rough number estimation? e.g. using GitHub's code search.
------
Another thing I realized is the interaction between the `_replace` functions and PFA: It can be used as an (inefficient?) way of creating a concat as a function handle: `$concat = str_prefix_replace("", ?, ?);` (with suffix_replace being a reverse concat).
Best regards
Tim Düsterhus
On Fri, 23 Jan 2026 at 09:31, Tim Düsterhus <tim@bastelstu.be> wrote:
Hi
Am 2026-01-22 19:28, schrieb Barel:
Following a comment by Tim Düsterhus (thanks!) and another comment in
the
PR, I have inverted the order of the parameters in the ensure and
remove
functions, so that they follow the parameter order in related functions
like str_contains() and str_starts_with()Thank you. I have given the RFC another look and have some polishing
comments:
In the “Exact semantics (per function)” example it would probably be
easier to understand if you would provide a userland implementation.
Folks are already used to reading PHP and there is no ambiguity about
the proposed behavior then. As a benefit, the implementation from the
RFC would directly be usable as a polyfill, e.g. for use in
https://github.com/symfony/polyfill. The previous “array_find” RFC might
be a good example here: https://wiki.php.net/rfc/array_findIn the “Backwards Incompatible Changes” section: Can you please
perform some research for a rough number estimation? e.g. using GitHub’s
code search.
Another thing I realized is the interaction between the
_replace
functions and PFA: It can be used as an (inefficient?) way of creating a
concat as a function handle:$concat = str_prefix_replace("", ?, ?);
(with suffix_replace being a reverse concat).Best regards
Tim Düsterhus
Tim, thanks for your suggestions, I updated the RFC
Cheers
Carlos
Hi,
It’s been 14 days since the last change to the RFC and there have been no further discussions, so the cooldown period is over and I would like to announce the start of the voting
Voting will commence next Monday 9th of February and will be announced in this list
Link to the RFC for reference: https://wiki.php.net/rfc/prefix_suffix_functions
Cheers
Carlos
Hi Carlos
On Fri, Feb 6, 2026 at 10:41 AM Barel <barel.barelon@gmail.com> wrote:
It's been 14 days since the last change to the RFC and there have been no further discussions, so the cooldown period is over and I would like to announce the start of the voting
Link to the RFC for reference: PHP: rfc:prefix_suffix_functions
Sorry for my late feedback.
What's the rationale for $subject being the last parameter only in
str_prefix_replace() and str_suffix_replace()? I feel pretty strongly
that the subject should always be the first parameter. We don't want
to add to the classic haystack/needle confusion.
Regards,
Ilija
On Fri, 6 Feb 2026 at 10:53, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
Hi Carlos
On Fri, Feb 6, 2026 at 10:41 AM Barel <barel.barelon@gmail.com> wrote:
It’s been 14 days since the last change to the RFC and there have been no further discussions, so the cooldown period is over and I would like to announce the start of the voting
Link to the RFC for reference: https://wiki.php.net/rfc/prefix_suffix_functions
Sorry for my late feedback.
What’s the rationale for $subject being the last parameter only in
str_prefix_replace() and str_suffix_replace()? I feel pretty strongly
that the subject should always be the first parameter. We don’t want
to add to the classic haystack/needle confusion.Regards,
Ilija
Hi Ilija
These new functions follow the format of their closest existing relatives, thus the _ensure and _remove functions follow the format of the str_starts_with, str_ends_with and str_contains functions where the subject is the first parameter, while the _replace functions follow the format of the str_replace and preg_replace functions where the subject is the last parameter. It is unfortunate that these two groups of functions follow different standards but I thought it would be better to keep as close to existing functions as possible
Cheers
Carlos
On 2/6/26 03:51, Ilija Tovilo wrote:
Hi Carlos
On Fri, Feb 6, 2026 at 10:41 AM Barel <barel.barelon@gmail.com> wrote:
It's been 14 days since the last change to the RFC and there have been no further discussions, so the cooldown period is over and I would like to announce the start of the voting
Link to the RFC for reference: PHP: rfc:prefix_suffix_functions
Sorry for my late feedback.
What's the rationale for $subject being the last parameter only in
str_prefix_replace() and str_suffix_replace()? I feel pretty strongly
that the subject should always be the first parameter. We don't want
to add to the classic haystack/needle confusion.Regards,
Ilija
I agree with Ilija that the subject should always be the first parameter.
I'm not necessarily against adding these functions to the language, but they seem ripe for a well-adopted userland library. As such, I'm on the fence about whether these belong in core.
Cheers,
Ben
While I am not a voting member of the community, I am unconvinced that there is a sufficient appetite from the PHP community for this new family of string functions.
I mean, when I discussed the possibility of array_transpose(), I could list nearly 100 Stack Overflow pages that called for such a function (without all the potential bugs involved with spreading techniques). https://meta.stackoverflow.com/q/417663/2943403
Do you see many calls for your proposed functions in the wild? Are there 5 questions on Stack Overflow where these functions provide a resounding benefit? I’ve hunted a little and haven’t found any, but I might be searching poorly. Are there pre-existing implementations in repos that we can observe?
In the absence of real demand, perhaps these should merely be in a userland library.
I also agree that the $subject should be the first parameter, like substr_replace().
Mick
On Sat, 7 Feb 2026 at 01:13, mickmackusa <mickmackusa@gmail.com> wrote:
While I am not a voting member of the community, I am unconvinced that there is a sufficient appetite from the PHP community for this new family of string functions.
I mean, when I discussed the possibility of array_transpose(), I could list nearly 100 Stack Overflow pages that called for such a function (without all the potential bugs involved with spreading techniques). https://meta.stackoverflow.com/q/417663/2943403
Do you see many calls for your proposed functions in the wild? Are there 5 questions on Stack Overflow where these functions provide a resounding benefit? I’ve hunted a little and haven’t found any, but I might be searching poorly. Are there pre-existing implementations in repos that we can observe?
In the absence of real demand, perhaps these should merely be in a userland library.
I also agree that the $subject should be the first parameter, like substr_replace().
Mick
Mick
Regarding the order of parameters, the parameters of the _replace function are much closer to what str_replace and preg_replace use instead of what substr_replace uses, that is why I prefer them to follow their closer relatives
Carlos
I see that there are different opinions regarding the order of the parameters for the _replace functions. Should I add a secondary vote to decide this order? If I do, does there need to be a new cooldown period before the vote? I am not sure about this, given this is my first RFC, would appreciate some clarification on this
Thanks!
Carlos
On 2/7/26 01:24, Barel wrote:
I see that there are different opinions regarding the order of the
parameters for the _replace functions. Should I add a secondary vote to
decide this order? If I do, does there need to be a new cooldown period
before the vote? I am not sure about this, given this is my first RFC,
would appreciate some clarification on thisThanks!
Carlos
"adding, changing or removing any voting widget" is considered a major change and requires a 14-day cooldown period. If you decide to add a secondary vote for the parameter order, you'd need to announce the change here on the list and allow 14 more days for discussion. This gives everyone enough chance to see the changes and make any comments before voting begins.
I would personally be in favor of either changing the proposed parameter order or adding a secondary vote to decide the order.
Cheers,
Ben
I have added a new section to the RFC explaining the discrepancy about parameter order for the _replace functions. I have also added a new secondary vote to decide this order. Would appreciate it if someone could confirm that this is all OK.
The voting expected to start this Monday has been cancelled and a new discussion/cooldown period has started.
Cheers
Carlos
On Sat, 7 Feb 2026 at 08:39, Ben Ramsey <ramsey@php.net> wrote:
On 2/7/26 01:24, Barel wrote:
I see that there are different opinions regarding the order of the
parameters for the _replace functions. Should I add a secondary vote to
decide this order? If I do, does there need to be a new cooldown period
before the vote? I am not sure about this, given this is my first RFC,
would appreciate some clarification on thisThanks!
Carlos
“adding, changing or removing any voting widget” is considered a major
change and requires a 14-day cooldown period. If you decide to add a
secondary vote for the parameter order, you’d need to announce the
change here on the list and allow 14 more days for discussion. This
gives everyone enough chance to see the changes and make any comments
before voting begins.I would personally be in favor of either changing the proposed parameter
order or adding a secondary vote to decide the order.Cheers,
Ben
Hi
On 2/7/26 09:21, Barel wrote:
I have added a new section to the RFC explaining the discrepancy about
parameter order for the _replace functions. I have also added a new
secondary vote to decide this order. Would appreciate it if someone could
confirm that this is all OK.
For the secondary vote you'll need to define a tie breaker. I assume the ties are broken in favor of `$subject` last, since that's what the RFC uses in all examples, but it will need to be clearly stated.
Personally I'm team “I don't think the functions are necessary, but if they are included, they should match str_replace()”.
Best regards
Tim Düsterhus
On Sun, 8 Feb 2026 at 14:55, Tim Düsterhus <tim@bastelstu.be> wrote:
For the secondary vote you’ll need to define a tie breaker. I assume the
ties are broken in favor of$subjectlast, since that’s what the RFC
uses in all examples, but it will need to be clearly stated.Personally I’m team “I don’t think the functions are necessary, but if
they are included, they should match str_replace()”.Best regards
Tim Düsterhus
Tim,
Thanks for the advice, updated