Adding in a case-insensitive version of str_contains View as Markdown

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?

mbstring doesn't deal with, or handle, locales, only charactersets. So that wouldn't be a good fit either.

There is grapheme_stripos, but that also doesn't do it locale dependent: https://www.php.net/manual/en/function.grapheme-stripos.php

PHP could really do with a locale aware, grapheme aware, set of Text utilities.

I have a prototype at https://github.com/derickr/php-text where this suggested function also would fit in.

cheers
Derick

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?

stripos is not locale dependent, str_icontains should use the same
case-folding rules and we're good and consistent. I'll vote Yes.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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.

Thanks for this.

In terms of real-life cases, we deal with a lot of datafeeds and
user-contributed content.
We have lots of rules engines that categorise or display data depending on
the content contained (and sometimes these rules change from time to time).
So for example, we have a rule that if the string contains the word
"exclusive" that it's displayed in a certain way.
We can add a rule that says if (str_contains($text, "exclusive"))... and if
want to include the ability for sentences to start with the word
"Exclusive" we currently have to write like this (as we like functions to
be truthy)... stripos(" ".$text, $exclusive) OR
str_contains(strtolower($text), "exclusive")

I'd just find it useful to have str_icontains/stri_contains available as
the same ASCII-folding variant that we have for other functions.

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.

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