Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108819
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>
In-Reply-To: <704fa268-6194-0ec2-d6b0-8f5efdf1009f@heigl.org>
Date: Tue, 3 Mar 2020 10:04:19 +0000
Message-ID: <CALKiJKpUQD8zwGnTHiYM1mGzhuwFNg0XP=mqVe_QS7yNaAMHKw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000062a37059ff06efd"
Subject: Re: [PHP-DEV] Proposal for a new basic function: str_contains
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000062a37059ff06efd
Content-Type: text/plain; charset="UTF-8"

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 could
> also be easily implemented in userland it misses one main thing IMO when
> 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 it
into the main string functions of the language would be the right approach.
Even if we changed all the existing functions to be "Unicode-aware", as was
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.

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000062a37059ff06efd--