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
