Re: Adding in a case-insensitive version of str_contains
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
Thread (10 messages)