Re: Proposal for a new basic function: str_contains

hello, On Fri, Feb 14, 2020, 6:54 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > On Fri, Feb 14, 2020 at 10:18 AM Philipp Tanlak <philipp.tanlak@gmail.com> > wrote: > > > Hello PHP Devs, > > > > I would like to propose the new basic function: str_contains. > > > > The goal of this proposal is to standardize on a function, to check > weather > > or not a string is contained in another string, which has a very common > > use-case in almost every PHP project. > > PHP Frameworks like Laravel create helper functions for this behavior > > because it is so ubiquitous. > > > > There are currently a couple of approaches to create such a behavior, > most > > commonly: > > <?php > > strpos($haystack, $needle) !== false; > > strstr($haystack, $needle) !== false; > > preg_match('/' . $needle . '/', $haystack) != 0; > > > > All of these functions serve the same purpose but are either not > intuitive, > > easy to get wrong (especially with the !== comparison) or hard to > remember > > for new PHP developers. > > > > The proposed signature for this function follows the conventions of other > > signatures of string functions and should look like this: > > > > str_contains(string $haystack, string $needle): bool > > > > This function is very easy to implement, has no side effects or backward > > compatibility issues. > > I've implemented this feature and created a pull request on GitHub ( > Link: > > https://github.com/php/php-src/pull/5179 ). > > > > To get this function into the PHP core, I will open up an RFC for this. > > But first, I would like to get your opinions and consensus on this > > proposal. > > > > What are your opinions on this proposal? > > > > Sounds good to me. This operation is needed often enough that it deserves a > dedicated function. > > I'd recommend leaving the proposal at only str_contains(), in particular: > > * Do not propose a case-insensitive variant. I believe this is really the > point on which the last str_starts_with/str_ends_with proposal failed. > > * Do not propose mb_str_contains(). Especially as no offsets are involved, > there is no reason to have this function. (For UTF-8, the behavior would be > exactly equivalent to str_contains.) > Btw, while some mbstring references I I mentioned, I do like the ICU search implementation as well. http://userguide.icu-project.org/collation/icu-string-search-service It handles a lot of cases based on locales. > Regards, > Nikita >