Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108577
MIME-Version: 1.0
References: <CAEo3Y-dTioEqVPW-7ewxsTWf6HRzp0F0TT+LqVZ3gBWB6MvreA@mail.gmail.com>
 <CAF+90c81CPKP+GN6Pqae4XnxC-BYDF9pOisd-naa38616xMQVw@mail.gmail.com>
In-Reply-To: <CAF+90c81CPKP+GN6Pqae4XnxC-BYDF9pOisd-naa38616xMQVw@mail.gmail.com>
Date: Fri, 14 Feb 2020 15:14:27 +0100
Message-ID: <CAEo3Y-f=UKfVUp5hh3vpBom6H6iJgm_mUBnC0JDv9mgoXm4k6g@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ee5078059e89d4b6"
Subject: Re: [PHP-DEV] Proposal for a new basic function: str_contains
From: philipp.tanlak@gmail.com (Philipp Tanlak)

--000000000000ee5078059e89d4b6
Content-Type: text/plain; charset="UTF-8"

Am Fr., 14. Feb. 2020 um 12:54 Uhr schrieb Nikita Popov <
nikita.ppv@gmail.com>:

> 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.)
>
> Regards,
> Nikita
>

I like to elaborate on Nikitas response: I don't think a mb_str_contains is
necessary, because the proposed function does not behave differently, if
the input strings are multibyte strings.
When searched for a multibyte string in another multibyte string, the
return value would consistently be true/false. The position/offset at which
the multibyte string was found is not relevant.
The reason for the existence of a strpos/mb_strpos is the fact, that the
returned position/offset varies depending on weather or not the string is a
multibyte string or not.

The only possible valid variants concerning multibyte and incasesensitivity
I see are:
* str_contains: works as expected with multibyte and non multibyte strings.
* mb_str_icontains: is the only valid option to do a incasesensitive search
for multibyte strings.

Unneeded variants I see are:
* mb_str_contains: does not behave differently when compared to
str_contains, as mentioned above.
* str_icontains: is a possible option but could be error prone for when
used with multibyte strings like UTF-8, as it is de facto the standard
nowadays.

I'm certain there would be confusion among php developers when the newly
proposed functions are only str_contains and mb_str_icontains.

Patrick ALLAERT:
Yes, it does have one: people having already defined a str_contains()
function in the global scope will have a PHP Fatal error:  Cannot redeclare
str_contains()

You are absolutely correct with this. Although functions added by
frameworks to the global scope are usually guarded by: if
(!function_exists('str_contains')) {}

--000000000000ee5078059e89d4b6--