Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127519
Precedence: bulk
MIME-Version: 1.0
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>
 <20AFBEA9-C3DA-4F6A-BD0A-112F86064316@php.net>
In-Reply-To: <20AFBEA9-C3DA-4F6A-BD0A-112F86064316@php.net>
Date: Sun, 1 Jun 2025 11:55:18 +0900
Message-ID: <CAEPPVa218KQh0xjgKx_+EHBNL4t3ux9X_KE6aGXs4Gg6oHrQOA@mail.gmail.com>
Subject: Re: [PHP-DEV] Adding in a case-insensitive version of str_contains
To: internals@lists.php.net, Derick Rethans <derick@php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: youkidearitai@gmail.com (youkidearitai)

2025=E5=B9=B46=E6=9C=881=E6=97=A5(=E6=97=A5) 1:07 Derick Rethans <derick@ph=
p.net>:
>
> On 31 May 2025 12:36:52 BST, youkidearitai <youkidearitai@gmail.com> wrot=
e:
> >2025=E5=B9=B45=E6=9C=8831=E6=97=A5(=E5=9C=9F) 19:41 Nikita Popov <php@np=
opov.com>:
> >>
> >> 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_mult=
ibyte_strings
> >>
> >>
> >> To make it a bit more explicit: The proposed str_icontains function do=
es 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 (whic=
h removed C locale support from this family of functions), there actually i=
s a pretty viable way forward to make the non-mbstring case-insensitive str=
ing 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* func=
tions, and the mb_stri* functions.)
> >>
> >
> >I agree that it's important to think about it in UTF-8.
> >
> >I think about UTF-8 support case folding function in past few days.
> >Maybe... It is like below?
> >
> >```
> >grapheme_setlocale($locale);
> >grapheme_icontains($haystack, $needle);
> >```
> >
> >First, grapheme_* function supports locale.
> >Second, add grapheme_icontains function for case insensitive version
> >for str_contains. .
>
> I don't think it's a good idea to rely on a global state containing the l=
ocale.
>
> cheers
> Derick

Hi, Derick (and Internals)

Thank you your feedback.
Well, Then I could find two ways.

First, grapheme_* functions add $locale parameter. For example in
grapheme_strpos.

```
 grapheme_strpos(string $haystack, string $needle, int $offset =3D 0,
string $locale): int|false
```

Second, Contain a locale in object instance (But I can't find just object).

By the way, intl is already exists Locale class.
https://www.php.net/manual/en/class.locale.php
But, it is not seems use anymore.

Regards
Yuya

--=20
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------