Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108821
MIME-Version: 1.0
References: <CAEo3Y-dTioEqVPW-7ewxsTWf6HRzp0F0TT+LqVZ3gBWB6MvreA@mail.gmail.com>
 <CAF+90c81CPKP+GN6Pqae4XnxC-BYDF9pOisd-naa38616xMQVw@mail.gmail.com>
 <CAEZPtU4ea0MQF=fv9=2HGPh9Xmc8nBT6QdtGAS0QARnszkE6kA@mail.gmail.com>
 <CALKiJKr_sqZO8BMCMC28nDqHG9_tgaVsX9v0Xw9H0OfSLz+7vQ@mail.gmail.com>
 <704fa268-6194-0ec2-d6b0-8f5efdf1009f@heigl.org> <CALKiJKpUQD8zwGnTHiYM1mGzhuwFNg0XP=mqVe_QS7yNaAMHKw@mail.gmail.com>
In-Reply-To: <CALKiJKpUQD8zwGnTHiYM1mGzhuwFNg0XP=mqVe_QS7yNaAMHKw@mail.gmail.com>
Date: Tue, 3 Mar 2020 14:29:07 +0100
Message-ID: <CAOWwgpmY9zqJ4NYR5bVha0NMaJC6tHH0nZHHKMcMo6OAcEfVzw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000af1d9a059ff34a10"
Subject: Re: [PHP-DEV] Proposal for a new basic function: str_contains
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000af1d9a059ff34a10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 3 mars 2020 =C3=A0 11:04, Rowan Tommins <rowan.collins@gmail.com> a
=C3=A9crit :

> On Tue, 3 Mar 2020 at 08:46, Andreas Heigl <andreas@heigl.org> wrote:
>
> >
> > While it is mainly aimed at being a mere convenience-function that coul=
d
> > also be easily implemented in userland it misses one main thing IMO whe=
n
> > handling unicode-strings: Normalization.
> >
> >
>
> While I would love to see more functionality for handling Unicode which
> didn't treat it as just another character set, I don't think sprinkling i=
t
> into the main string functions of the language would be the right approac=
h.
> Even if we changed all the existing functions to be "Unicode-aware", as w=
as
> planned for PHP 6, the resulting API would not handle all cases correctly=
.
>
> In this case, a Unicode-based string API ought to provide at least two
> variants of "contains", as options or separate functions:
>
> - a version which matches on code point, for answering queries like "does
> this string contain right-to-left override characters?"
> - at least one form of normalization, but probably several
>
> If there was serious work on a new string API in progress, a freeze on
> additions to the current API would make sense; but right now, the
> byte-based string API is what we have, and I think this function is a
> sensible addition to it.
>


FYI, I wrote a String handling lib, shipped as Symfony String:
- doc: https://symfony.com/doc/current/components/string.html
- src: https://github.com/symfony/string

TL;DR, it provides 3 classes of value objects, dealing with bytes, code
points and grapheme cluster (~=3D normalized unicode)

It makes no sense to have `str_contains()` or any global function able to
deal with Unicode normalization *unless* the PHP string values embed their
unit system (one of: bytes, codepoints or graphemes).

With this rationale, I agree with Rowan: PHP's native string functions deal
with bytes. So should str_contains(). Other unit systems can be implemented
in userland (until PHP implements something similar to Symfony String in
core - but that's another topic.)

Nicolas

--000000000000af1d9a059ff34a10--