Everything

php

[RFC] [Discussion] Prefix and Suffix Functions

php.internals

Barel

222 days ago

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

Tim Düsterhus

222 days ago

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 suffixes
>
> This 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

Barel

222 days ago

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:

Tim Düsterhus

221 days ago

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
https://github.com/symfony/polyfill. The previous “array_find” RFC might
be a good example here: https://wiki.php.net/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

Barel

221 days ago

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:
>
> 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
> https://github.com/symfony/polyfill. The previous “array_find” RFC might
> be a good example here: https://wiki.php.net/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
>

Tim, thanks for your suggestions, I updated the RFC

Cheers

Carlos

Barel

207 days ago

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

Ilija Tovilo

207 days ago

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

Barel

207 days ago

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

Ben Ramsey

206 days ago

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: 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

mickmackusa

206 days ago

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

Barel

206 days ago

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

Barel

206 days ago

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

Ben Ramsey

206 days ago

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 this
>
> Thanks!
>
> 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

Barel

187 days ago

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

Tim Düsterhus

186 days ago

Hi

Am 2026-02-26 18:52, schrieb Barel:

> 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.

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