Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108634
MIME-Version: 1.0
References: <CAEo3Y-dTioEqVPW-7ewxsTWf6HRzp0F0TT+LqVZ3gBWB6MvreA@mail.gmail.com>
 <4a0f4d30-c8d3-0274-413f-0f4c582418d0@aegir.sexy> <CAFPFaMK=83QBaMCgxtQ7GAss3S6PLhbvMDKCqnU26nDRNxf+Zw@mail.gmail.com>
In-Reply-To: <CAFPFaMK=83QBaMCgxtQ7GAss3S6PLhbvMDKCqnU26nDRNxf+Zw@mail.gmail.com>
Date: Mon, 17 Feb 2020 08:18:11 +0100
Message-ID: <CAC5V6ghhBUtS7wki+de17bwrWOh9bpfx9xeBxNOZibVbr84jFQ@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Aegir Leet <aegir@aegir.sexy>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Proposal for a new basic function: str_contains
From: guilliam.xavier@gmail.com (Guilliam Xavier)

On Fri, Feb 14, 2020 at 11:14 AM G. P. B. <george.banyard@gmail.com> wrote:
>
> Moreover, checking for a substring to start/end a string seems
> to be
> fitting for the current strpos functions.

Maybe in terms of semantics (`0 === strpos($haystack, $needle)`), but
suboptimal in terms of performance, especially when $haystack is a
*very long* string which *doesn't* contain $needle, strpos() will
vainly search along the whole string, while a specialized function
would stop as soon as possible (which is also the case of existing
strncmp() but you need to write `0 === strncmp($haystack, $needle,
strlen($needle))`, arguably not really the cleanest code...).

For "contains" you have to search along the whole string anyway, so
`str_contains()` is "just" `false !== strpos()` but cleaner.

To be clear, I'm not against the current proposal (rather for
actually) [I just would want `str_{starts,ends}_with` even more
(without case-insensitive nor multibyte variants)]

-- 
Guilliam Xavier

On Fri, Feb 14, 2020 at 11:14 AM G. P. B. <george.banyard@gmail.com> wrote:
>
> On Fri, 14 Feb 2020 at 10:58, Aegir Leet <aegir@aegir.sexy> wrote:
>
> > I generally like the idea, but it seems many (most?) real-world
> > implementations actually use mb_strpos() !== false by default.
> >
> >
> > https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215
> >
> > https://github.com/illuminate/support/blob/6eff6cff19f7ad5540b9a61a9fb3612ca8218c19/Str.php#L157-L166
> >
> > So there should definitely be an mb_str_contains in ext/mbstring in
> > addition to the regular str_contains proposed here.
> >
>
> The biggest reason to have an mb_* variant if for when comparing with case
> insensitivity.
> The only other reason is if you need to check a string which is in a
> different encoding,
> which is, I'm assuming, is a quasi non-existent problem as everything
> things is UTF-8
> nowadays.
>
> The reason why I personally voted no on the previous RFC was that I don't
> see the
> value of having functions checking if a string starts/ends with a sequence
> but not a
> general one. Moreover, checking for a substring to start/end a string seems
> to be
> fitting for the current strpos functions.
>
> This function on it's own is way more reasonable and useful to add IMHO
>
> Best regards
>
> George P. Banyard



-- 
Guilliam Xavier