On Fri, Feb 14, 2020 at 10:18 AM Philipp Tanlak <philipp.tan...@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.)
Regards,
Nikita
