Re: Proposal for a new basic function: str_contains
| From: | Guilliam Xavier | Date: | Mon, 17 Feb 2020 07:18:11 +0000 |
| Subject: | Re: Proposal for a new basic function: str_contains | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108634@lists.php.net to get a copy of this message | ||
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