Everything

php

Home » Project » Newsgroups » php.internals » [VOTE] str_icontains »

[VOTE] str_icontains

php.internals

Adam Cable

1 year ago

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

Tim Düsterhus

1 year ago

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

Adam Cable

1 year ago

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

Tim Düsterhus

1 year ago

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

Andreas Heigl

1 year ago

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                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg                          |
+---------------------------------------------------------------------+

youkidearitai

1 year ago

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
- https://github.com/youkidearitai
-----------------------------

Derick Rethans

1 year ago

On Tue, 1 Jul 2025, Adam Cable wrote:

> 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

Adam Cable

1 year ago

On Tue, Jul 1, 2025 at 8:01 AM Adam Cable <adamcable@gmail.com> wrote:

> 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

Tim Düsterhus

1 year ago

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