Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120512 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30944 invoked from network); 2 Jun 2023 12:18:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Jun 2023 12:18:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0EEB8180089 for ; Fri, 2 Jun 2023 05:18:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS16276 192.99.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns563681.ip-192-99-44.net [192.99.44.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 2 Jun 2023 05:18:07 -0700 (PDT) Message-ID: <90d93f53-ea6f-8325-62c2-ca33a17aa492@processus.org> Date: Fri, 2 Jun 2023 14:18:04 +0200 MIME-Version: 1.0 To: internals@lists.php.net References: <97308c1d-e9f0-e28d-78ba-11da2a136ee6@fide.pl> <6c66ad82-7616-4b22-8961-494b557a3def@app.fastmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / Authentication-Results: processus.org; auth=pass smtp.mailfrom=pierre-php@processus.org Subject: Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions From: pierre-php@processus.org (Pierre) Le 02/06/2023 à 10:57, Janusz Szczypka a écrit : > You are right about speed penalty for using those functions over > simple loops, however if we would stick to that point of view, we > should deprecate and remove array_filter, array_map, array_walk, > array_u... I'm not sure they deserve deprecation, but I think that proposal may be the right time to talk about adding a real iterable API in PHP core for every one to use, a complete and consistent one, that would work on all traversable data structures, https://github.com/nikic/iter is perfect in my opinion for a good start, and would really deserve to be in SPL, and maintained along with core, and be usable without any composer dependencies. PHP is really lacking a complete enumerable / iterable / traversable API. Maybe this is time to design and add one ? -- Pierre