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-27 14:31, 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.
Thank you for quickly creating the separate thread. I also noticed that
you forgot to move the RFC to the voting phase in the overview. I just
did that:
https://wiki.php.net/rfc?do=diff&rev2%5B0%5D=1772199822&rev2%5B1%5D=1772203366&difftype=sidebyside
Please remember to also move it to the correct section once the vote
finishes.
Best regards
Tim Düsterhus
Hey Carlos,
Hi everyone,
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.Cheers
Carlos
I like this RFC very much. I think every addition to the standard
library needs to be well considered, but this one definitely crosses the
bar.
Simple prefix and suffix operations are quite common - especially in
scripting and manipulation of well-known strings.
While you certainly can write these with substr, it often either
duplicates the string for the length or just hardcodes the length, both
of which are equally ugly.
Sure, users can write helper functions for these, but I find below a
certain size, users typically don't.
Thus I think this proposed change will lead to simpler and less
error-prone code.
Bob
Hey 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/129842The vote will be open for 2 weeks (and a few hours), closing on March
13th at midnight UTC.Cheers
Carlos
I like this RFC very much. I think every addition to the standard
library needs to be well considered, but this one definitely crosses
the bar.Simple prefix and suffix operations are quite common - especially in
scripting and manipulation of well-known strings.While you certainly can write these with substr, it often either
duplicates the string for the length or just hardcodes the length, both
of which are equally ugly.
Sure, users can write helper functions for these, but I find below a
certain size, users typically don't.Thus I think this proposed change will lead to simpler and less
error-prone code.
I know I personally would use the ensure() functions quite frequently in a project of mine. Hence my yes vote.
Though I would also question why so many people are voting for $subject-last for the secondary vote.
--Larry Garfield
Hey Larry,
Though I would also question why so many people are voting for $subject-last for the secondary vote.
--Larry Garfield
The two-argument variants are consistent with e.g. addcslashes (one
subject operated on with an argument) - so that's perfectly consistent.
Then for replacing, you want consistency with str_replace, and
preg_replace and such.
Bob
Hey Larry,
Though I would also question why so many people are voting for $subject-last for the secondary vote.
The two-argument variants are consistent with e.g. addcslashes (one
subject operated on with an argument) - so that's perfectly consistent.Then for replacing, you want consistency with str_replace, and
preg_replace and such.
Maybe consistently inconsistent. ;) In my opinion, it's much better to
not keep repeating the same mistake, pick a standard and stick with
it. Subject-first always works. I wouldn't think many people want to
internalize the placement of the subject based on the kind of string
replacement function.
Ilija
Hey Larry,
Though I would also question why so many people are voting for $subject-last for the secondary vote.
The two-argument variants are consistent with e.g. addcslashes (one
subject operated on with an argument) - so that's perfectly consistent.Then for replacing, you want consistency with str_replace, and
preg_replace and such.Maybe consistently inconsistent. ;) In my opinion, it's much better to
not keep repeating the same mistake, pick a standard and stick with
it. Subject-first always works. I wouldn't think many people want to
internalize the placement of the subject based on the kind of string
replacement function.Ilija
I think $subject should be first because these functions align with
other str_prefix_* functions. If the names were inverted, i.e.
str_ensure_prefix, then I would vote for $subject to be last because
str_replace and str_replace_suffix are more aligned.
Hey Larry,
Though I would also question why so many people are voting for
$subject-last for the secondary vote.The two-argument variants are consistent with e.g. addcslashes (one
subject operated on with an argument) - so that's perfectly consistent.Then for replacing, you want consistency with str_replace, and
preg_replace and such.Maybe consistently inconsistent. ;) In my opinion, it's much better to
not keep repeating the same mistake, pick a standard and stick with
it. Subject-first always works. I wouldn't think many people want to
internalize the placement of the subject based on the kind of string
replacement function.
Indeed, alternating parameter order based on the type of operation would be
just frustrating.
Consistency with existing functions is nice in principle, but not all
historic precedents are good.
Am 27.02.2026 um 14:31 schrieb Barel barel.barelon@gmail.com:
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
My reason to vote no was that
a) it is sort of a matrix of functions (prefix|suffix x ensure|remove|replace) a doing something very similar
b) there are several downsides to these specific implementations
The downsides I see at a first glance:
- case sensitive: str_suffix_replace(".jpeg", ".jpg", $filename) does not work with "Image.JPEG"
- *_ensure doesn't handle multiples: str_suffix_ensure($path, '/') does not handle "/api//"
This leads me to the conclusion that I'd probably stick to the old-school use of preg_replace which handles all the things these functions try to solve.
And while I agree that regular expressions are a bit harder to read they (to me) are simple enough while not having these downsides.
E.g. I would rewrite
$file = str_suffix_replace('.jpeg', '.jpg', $file);
as
$file = preg_replace('#.jpeg$#i', '.jpg', $file); # Case insentive, easily extended also handle jpe and jfif
And instead of
$path = str_suffix_ensure($path, '/');
I would write
$path1 = preg_replace('#/*$#', '/', $path, 1); # Ensure one single slashes at the end
or maybe even
$path = preg_replace('#/+#', '/', "$path/"); # Also normalizes all multiple slashes in the path
Side-note: Regular expressions handle all the stuff described in the Future Scope section.
Some people like long and descriptive special functions for (depending on the context) common cases but I realized that I often prefer being able to reuse powerful functionality instead of having to guess if a specialized function might exists even with modern dev environments make finding the right function easier. YMMV.
Regards,
- Chris