Re: Proposal: addition of array_find() and array_find_key() functions

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