Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123248
Message-ID: <4b86febc-b4ee-4644-bcfd-094fcf79e12e@wcflabs.de>
Date: Wed, 1 May 2024 22:38:02 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC [Discussion]: array_find
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
References: <24e4529d-0b75-44de-90ef-34de5dfb1c99@wcflabs.de>
 <278889be-82ab-4827-a9e7-801b5ba2d8f8@app.fastmail.com>
 <45b726f4-8085-43e2-b701-6b35bc249409@wcflabs.de>
 <d8a92e7a-539e-4753-bd27-5d59b17779ba@bastelstu.be>
 <23f2275a-7a26-4f8a-b5c1-d92ed0298d1a@bastelstu.be>
Content-Language: de-DE
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <23f2275a-7a26-4f8a-b5c1-d92ed0298d1a@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: josh@wcflabs.de ("=?UTF-8?Q?Joshua_R=C3=BCsweg?=")

Hi

On 19.04.24 23:29, Tim Düsterhus wrote:> Thinking about this: I believe 
that it would make sense to bundle
> array_any and array_every (or array_all, see below) within the same RFC 
> due to the similarity. It can be a separate vote for those two, but 
> having the option of getting all three would probably alleviate my 
> concerns of adding new array functions piecemeal.
> 
> The implementation should be trivial, because it effectively just 
> changes the return type. Nevertheless I'm happy to assist should any 
> issues arise.
> 
> As for the naming:
> 
> JavaScript: every      + some
> Haskell   : all        + any
> Rust      : all        + any
> C++       : all_of     + any_of + none_of
> Java      : allMatch   + anyMatch (in java.util.stream.Stream)
> Swift     : allSatisfy + contains(where: …)
> 
> It appears the commonly used choice is all + any.

Thanks for your suggestion! I have added the `array_any` and `array_all` 
functions to the RFC accordingly.

Cheers

Josh