[PHP-DEV] [VOTE] str_icontains

Mailing Lists php.internals
1

Hi,

Voting just opened on the “str_icontains” RFC.

Please find the following resources:

RFC: https://wiki.php.net/rfc/str_icontains
Discussion: https://externals.io/message/127667
PR: https://github.com/php/php-src/pull/18705

As with every RFC, a 2/3 majority is required.
Voting ends 2025-07-16 00:00:00 UTC.

Thanks,
Adam

2

Hi

Am 2025-07-01 09:01, schrieb Adam Cable:

Voting just opened on the "str_icontains" RFC.

Please find the following resources:

RFC: PHP: rfc:str_icontains
Discussion: [RFC] str_icontains - Externals
PR: Create str_icontains PHP function by adamcable · Pull Request #18705 · php/php-src · GitHub

Thank you for your RFC. While I initially said “seems easy enough” in the PR and I also believe that making the function ASCII-only for consistency, I ultimately decided to vote against the RFC.

My main reason is that I do not like how this function is added in a standalone fashion without a bigger picture. As mentioned in the PR, `str_starts_with()` and `str_ends_with()` are obvious companion functions.

And ultimately calling `strtolower()` on both parameters before passing them to `str_contains()` is quite explicit in what it does (and would also resolve the Unicode vs ASCII confusion that others expressed). Alternatively `stripos()` would also work.

Best regards
Tim Düsterhus

3

On Tue, Jul 1, 2025 at 8:24 AM Tim Düsterhus <tim@bastelstu.be> wrote:

Hi

Am 2025-07-01 09:01, schrieb Adam Cable:

Voting just opened on the “str_icontains” RFC.

Please find the following resources:

RFC: https://wiki.php.net/rfc/str_icontains
Discussion: https://externals.io/message/127667
PR: https://github.com/php/php-src/pull/18705

Thank you for your RFC. While I initially said “seems easy enough” in
the PR and I also believe that making the function ASCII-only for
consistency, I ultimately decided to vote against the RFC.

My main reason is that I do not like how this function is added in a
standalone fashion without a bigger picture. As mentioned in the PR,
str_starts_with() and str_ends_with() are obvious companion
functions.

And ultimately calling strtolower() on both parameters before passing
them to str_contains() is quite explicit in what it does (and would
also resolve the Unicode vs ASCII confusion that others expressed).
Alternatively stripos() would also work.

Best regards
Tim Düsterhus

Hi Tim,

Thanks for giving an explanation of your vote, thank you.
I had assumed that going with a small RFC for this would be easier than trying to get str_starts/ends_with through at the same time, as noted in the PR:

“I’ll create a RFC for this, and if successful look to do the same with str_starts_with and str_ends_with”

Thanks,
Adam

4

Hey Adam

Am 01.07.25 um 09:01 schrieb Adam Cable:

Hi,

Voting just opened on the "str_icontains" RFC.

I have also voted *no* on this RFC for 2 reasons.

1. I also think that - if we go that route - the other convenience functions around strpos need to be taken into account here as well.

2. case-insensitivity isn't as easy as it looks. Even based on ASCII there are cases - depending on the used alphabet - where it's not as easy. And by using any of the already existing options for case-folding (strtolower, mb_strtolower, Transliterator::transliterate() to name a few) on the passed parameters the results are much more reliable and less confusing depending on the use-case.

To get an idea where stuff gets odd: Which one is the correct lower-case letter for "I" (U+0049)... Usually it's "i" (U+0069). Unless you are in turkey (or some other parts of that area) where it is "ı" (U+0131). Because the "i" (U+0069) is the lower case version of "İ" (U+0130)...

So by using explicit conversions of the input data before passing them to str_contains (or any of the other functions) we get a more predictable result than by using `str_icontains` which might or might not do what I expect...

Regards

Andreas

--
                                                               ,
                                                              (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| Appointments - Nextcloud |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

5

On Tue, 1 Jul 2025, Adam Cable wrote:

Hi,

Voting just opened on the "str_icontains" RFC.

Please find the following resources:

RFC: PHP: rfc:str_icontains
Discussion: [RFC] str_icontains - Externals
PR: Create str_icontains PHP function by adamcable · Pull Request #18705 · php/php-src · GitHub

As with every RFC, a 2/3 majority is required.
Voting ends 2025-07-16 00:00:00 UTC.

I have voted "no" on this, as it's 2025, and we really shouldn't be
introducing ASCII-only functions.

cheers,
Derick

6

Hi

Am 2025-07-01 10:17, schrieb Adam Cable:

Thanks for giving an explanation of your vote, thank you.
I had assumed that going with a small RFC for this would be easier than
trying to get str_starts/ends_with through at the same time, as noted in
the PR:

"I'll create a RFC for this, and if successful look to do the same with
str_starts_with and str_ends_with"

I generally prefer splitting RFCs into its “atomic parts” that make sense on its own, since that makes it easier to discuss the RFC and ensures that features compose well.

However in this case, the other functions are *so similar* in practice that it would make sense to handle them all at the same time, including figuring out naming / the bigger picture. Otherwise we might end up with `str_icontains()` and `stri_starts_with()` (since `str_istarts_with()` is ugly by the folks discussing the next RFC) - which clearly is undesirable.

Best regards
Tim Düsterhus

7

Hi, Adam, and internals

I don't have a authority of vote.
But I don't think make sense to support case-insensitive only ASCII of
str_contains.
Because it benefit is only ASCII region.
I want to also supports Unicode case-insensitive for str_starts_with
and str_ends_with.

I'm glad to discuss to improve a Unicode support with PHP community.

Thanks
Yuya.

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
-----------------------------