Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120503 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60799 invoked from network); 1 Jun 2023 17:22:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jun 2023 17:22:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5279D180511 for ; Thu, 1 Jun 2023 10:22:37 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 1 Jun 2023 10:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1685640154; bh=mT/xfSqQz0y9Dbcjm0Nn1t9mhhV4/4vMZZGvEiK7Zf8=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type:from:to:cc:subject:message-id; b=FjK6UXE7TdmJJ8j44yk15rdoTK78oKgHqsi6ljr/Z/iWQBhq2gJ5N6E1/umFXLWlY KatdRBwJMhH9dTuT3oXgoYBt6LMWrJ3OZbk52WF9ehgvjoRlBbbtuKzid0WAaadt8W ht8wa/zdFNGJ/9HQU3WCkOC9cT5Qq5WPVJ/CwJS8Mt1mE9pbltKQtmaqQ520o2poUw GpA3DETwaRInELOFUA6wG1M73Al4YOfvlpI0JQl3E9fuoUuCurvLABqBf411NY0cvc m1BGiblW1tX6g0Hi9/qWvFbFEsJbajjzhv1j1dZR82YuhBhR/VOsMMbMdjiymPynk+ HyEj33BYly6ww== Message-ID: <5e2e1efa-1dfa-64ea-354b-36fe9cc7b4e5@bastelstu.be> Date: Thu, 1 Jun 2023 19:22:34 +0200 MIME-Version: 1.0 To: php internals References: <97308c1d-e9f0-e28d-78ba-11da2a136ee6@fide.pl> <59ab68ce-8634-4ec5-92ae-ea46a04d774f@app.fastmail.com> Content-Language: en-US In-Reply-To: <59ab68ce-8634-4ec5-92ae-ea46a04d774f@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) Hi On 6/1/23 18:29, Larry Garfield wrote: > As with the array_group thread: > > What is the argument to put these functions in hard to update C, rather than PHP that is easy to download with Composer? "could be a nice addition" is not a compelling argument. Is it substantially faster? It is truly universally used? Does it correct some security concern? > I am not sure if "hard to update" is a argument that applies here: There is only one reasonable implementation of array_find and thus once the function is written it is exceedingly unlikely to need any updates. When was the last time `array_filter`, which is likely the most similar existing function, needed an update? From the list you've given, "universally used" appears to be the most fitting description. A programming language needs a reasonable standard library and `array_find()` [1] is something that should pop up reasonably often in "functional array processing". It's available in various languages [2]. My only concern is that this either is another function that either instead of working on any iterable, works on arrays and arrays only - or a function that is inconsistent with the rest of the array_* functions. See also the discussion here: https://externals.io/message/118896#118896 Best regards Tim Düsterhus [1] As well as array_any() and array_all(). [2] JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find Rust: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.find Haskell: https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-List.html#v:find C++: https://en.cppreference.com/w/cpp/algorithm/find