Proposal for a new basic function: str_contains

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

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')) {}

hello,

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