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:
https://wiki.php.net/rfc/prefix_suffix_functions
Please 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/129767
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
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
likestr_contains()andstr_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_find -
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
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
likestr_contains()andstr_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
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 Carlos
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 votingLink to the RFC for reference:
https://wiki.php.net/rfc/prefix_suffix_functionsSorry 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
Hi Carlos
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
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
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/2943403Do 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
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
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
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
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 matchstr_replace()”.Best regards
Tim Düsterhus
Tim,
Thanks for the advice, updated
Hi
It's been 15 days since the last update so I would like to announce the
start of the voting phase for this RFC. Voting will start next Thursday
26th of February
A link to the RFC:
https://wiki.php.net/rfc/prefix_suffix_functions
Cheers
Carlos
Hi everyone,
This is to announce the opening of the vote for the Prefix and Suffix
Functions RFC
RFC: https://wiki.php.net/rfc/prefix_suffix_functions
Discussion thread: https://news-web.php.net/php.internals/129842
The vote will be open for 2 weeks (and a few hours), closing on March
13th at midnight UTC.
Cheers
Carlos
Hi
Am 2026-02-26 18:52, schrieb Barel:
This is to announce the opening of the vote for the Prefix and Suffix
Functions RFCRFC: https://wiki.php.net/rfc/prefix_suffix_functions
Discussion thread: https://news-web.php.net/php.internals/129842The vote will be open for 2 weeks (and a few hours), closing on March
13th at midnight UTC.
Note that while you properly adjusted the title to include [VOTE], it
appears that didn't create a “fresh thread”, but instead replied to the
existing mailing list thread. As a result, the voting announcement might
be a little buried in email clients that take threading into account.
The same is true for Externals.
I don't think this is a significant issue that warrants an adjustment of
the vote, but please send a second announcement in a fresh thread (as an
new email, not using “Reply”).
Best regards
Tim Düsterhus