Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127518
Date: Sat, 31 May 2025 17:04:06 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Adding in a case-insensitive version of str_contains
User-Agent: K-9 Mail for Android
In-Reply-To: <CAEPPVa1wmho-YngwYyivUcPny8JCOxfrBDhnnNToicsjQNku0w@mail.gmail.com>
References: <CADuktwNsNK3vRyJqBwMDL07cy1GAGVCkBpCxAs5DTzfEqVy86Q@mail.gmail.com> <CAGBsUrf4KRhknui9=Ap94WRBVDD7K_LviT6_Otv4RqPKHYHKYg@mail.gmail.com> <2a626b9f-292b-4fc2-a023-0b0db9a64ede@app.fastmail.com> <CAEPPVa1wmho-YngwYyivUcPny8JCOxfrBDhnnNToicsjQNku0w@mail.gmail.com>
Message-ID: <20AFBEA9-C3DA-4F6A-BD0A-112F86064316@php.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: derick@php.net (Derick Rethans)

On 31 May 2025 12:36:52 BST, youkidearitai <youkidearitai@gmail=2Ecom> wrot=
e:
>2025=E5=B9=B45=E6=9C=8831=E6=97=A5(=E5=9C=9F) 19:41 Nikita Popov <php@npo=
pov=2Ecom>:
>>
>> On Thu, May 29, 2025, at 23:00, Kamil Tekiela wrote:
>>
>> As I understand, it was a conscious decision not to add this function
>> when str_contains was created=2E The reason is that case sensitivity is
>> locale-dependent, and for such use cases, mbstring extension is better
>> [1] & [2]=2E Do you think that locale is a concern here, and if not,
>> why? Would it be a good idea to add mb_str_icontains instead?
>>
>> If you're going to propose an RFC for this, it would be a good idea to
>> explain what the real life use case for it is=2E While str_contains is
>> very useful for checking the existence of a byte-string within another
>> byte-string, a case-sensitive check doesn't seem to have much use=2E
>>
>> [1]: https://stackoverflow=2Ecom/a/63121809/1839439
>> [2]: https://wiki=2Ephp=2Enet/rfc/str_contains#case-insensitivity_and_m=
ultibyte_strings
>>
>>
>> To make it a bit more explicit: The proposed str_icontains function doe=
s not support UTF-8=2E It would only be case-insensitive on ASCII character=
s=2E Do we really want to add new functions that do not properly handle UTF=
-8?
>>
>> I think that thanks to https://wiki=2Ephp=2Enet/rfc/strtolower-ascii (w=
hich removed C locale support from this family of functions), there actuall=
y is a pretty viable way forward to make the non-mbstring case-insensitive =
string functions useful again: Make them work on UTF-8=2E (In the sense of =
using Unicode case folding and case mapping on UTF-8, while still returning=
 code unit offsets=2E This would make them superior to both the current str=
i* functions, and the mb_stri* functions=2E)
>>
>
>I agree that it's important to think about it in UTF-8=2E
>
>I think about UTF-8 support case folding function in past few days=2E
>Maybe=2E=2E=2E It is like below?
>
>```
>grapheme_setlocale($locale);
>grapheme_icontains($haystack, $needle);
>```
>
>First, grapheme_* function supports locale=2E
>Second, add grapheme_icontains function for case insensitive version
>for str_contains=2E =2E

I don't think it's a good idea to rely on a global state containing the lo=
cale=2E

cheers
Derick