Re: Proposal for a new basic function: str_contains

From: 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

« previous php.internals (#108634) next »