[VOTE] str_icontains

1 month ago by tim@bastelstu.be — view source

unread

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

1 month ago by Adam Cable — view source

unread

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

1 month ago by tim@bastelstu.be — view source

unread

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

1 month ago by Andreas Heigl — view source

unread

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.

I also think that - if we go that route - the other convenience
functions around strpos need to be taken into account here as well.
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 |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

1 month ago by youkidearitai — view source

unread

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)

1 month ago by Derick Rethans — view source

unread

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.

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

cheers,
Derick

1 month ago by Adam Cable — view source

unread

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

This was declined with 6 votes to 11.
Thanks to everyone for voting.
Really appreciate everything that the custodians of PHP do to keep the
language moving forward :)

Best,
Adam

1 month ago by tim@bastelstu.be — view source

unread

Hi

Am 2025-07-16 08:13, schrieb Adam Cable:

This was declined with 6 votes to 11.
Thanks to everyone for voting.
Really appreciate everything that the custodians of PHP do to keep the
language moving forward :)

Even though the RFC was ultimately declined, I'd like to send my note of
appreciation with regard to how well-written and well-researched your
first RFC was. Looking forward to see with what you come up in the
future :-)

Best regards
Tim Düsterhus