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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
