Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127515
Feedback-ID: i1199467b:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 31 May 2025 12:34:58 +0200
To: "Kamil Tekiela" <tekiela246@gmail.com>, "Adam Cable" <adamcable@gmail.com>
Cc: "Levi Morrison" <internals@lists.php.net>
Message-ID: <2a626b9f-292b-4fc2-a023-0b0db9a64ede@app.fastmail.com>
In-Reply-To: 
 <CAGBsUrf4KRhknui9=Ap94WRBVDD7K_LviT6_Otv4RqPKHYHKYg@mail.gmail.com>
References: 
 <CADuktwNsNK3vRyJqBwMDL07cy1GAGVCkBpCxAs5DTzfEqVy86Q@mail.gmail.com>
 <CAGBsUrf4KRhknui9=Ap94WRBVDD7K_LviT6_Otv4RqPKHYHKYg@mail.gmail.com>
Subject: Re: [PHP-DEV] Adding in a case-insensitive version of str_contains
Content-Type: multipart/alternative;
 boundary=0088f4d3b94f435ab0847de062a59b1c
From: php@npopov.com ("Nikita Popov")

--0088f4d3b94f435ab0847de062a59b1c
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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. The reason is that case sensitivity is
> locale-dependent, and for such use cases, mbstring extension is better
> [1] & [2]. 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. 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.
> 
> [1]: https://stackoverflow.com/a/63121809/1839439
> [2]: https://wiki.php.net/rfc/str_contains#case-insensitivity_and_multibyte_strings

To make it a bit more explicit: The proposed str_icontains function does not support UTF-8. It would only be case-insensitive on ASCII characters. Do we really want to add new functions that do not properly handle UTF-8?

I think that thanks to https://wiki.php.net/rfc/strtolower-ascii (which removed C locale support from this family of functions), there actually is a pretty viable way forward to make the non-mbstring case-insensitive string functions useful again: Make them work on UTF-8. (In the sense of using Unicode case folding and case mapping on UTF-8, while still returning code unit offsets. This would make them superior to both the current stri* functions, and the mb_stri* functions.)

Regards,
Nikita
--0088f4d3b94f435ab0847de062a59b1c
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Thu, May =
29, 2025, at 23:00, Kamil Tekiela wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>As I understand, it was a conscious decision n=
ot to add this function</div><div>when str_contains was created. The rea=
son is that case sensitivity is</div><div>locale-dependent, and for such=
 use cases, mbstring extension is better</div><div>[1] &amp; [2]. Do you=
 think that locale is a concern here, and if not,</div><div>why? Would i=
t be a good idea to add mb_str_icontains instead?</div><div><br></div><d=
iv>If you're going to propose an RFC for this, it would be a good idea t=
o</div><div>explain what the real life use case for it is. While str_con=
tains is</div><div>very useful for checking the existence of a byte-stri=
ng within another</div><div>byte-string, a case-sensitive check doesn't =
seem to have much use.</div><div><br></div><div>[1]:&nbsp;<a href=3D"htt=
ps://stackoverflow.com/a/63121809/1839439">https://stackoverflow.com/a/6=
3121809/1839439</a></div><div>[2]:&nbsp;<a href=3D"https://wiki.php.net/=
rfc/str_contains#case-insensitivity_and_multibyte_strings">https://wiki.=
php.net/rfc/str_contains#case-insensitivity_and_multibyte_strings</a></d=
iv></blockquote><div><br></div><div>To make it a bit more explicit: The =
proposed str_icontains function does not support UTF-8. It would only be=
 case-insensitive on ASCII characters. Do we really want to add new func=
tions that do not properly handle UTF-8?</div><div><br></div><div>I thin=
k that thanks to <a href=3D"https://wiki.php.net/rfc/strtolower-ascii">h=
ttps://wiki.php.net/rfc/strtolower-ascii</a> (which removed C locale sup=
port from this family of functions), there actually is a pretty viable w=
ay forward to make the non-mbstring case-insensitive string functions us=
eful again: Make them work on UTF-8. (In the sense of using Unicode case=
 folding and case mapping on UTF-8, while still returning code unit offs=
ets. This would make them superior to both the current stri* functions, =
and the mb_stri* functions.)<br></div><div><br></div><div>Regards,</div>=
<div>Nikita</div></body></html>
--0088f4d3b94f435ab0847de062a59b1c--