Hi On 4/9/24 21:49, Tim Düsterhus wrote:
However I'm not sure if adding new array functions piecemeal is the right choice at this point. array_any and array_every are conceptually very similar to array_find and are missing as well. In fact array_any($cb, $array) = array_find($cb, $array, true) !== null and array_every($cb, $array) = !array_any($negatedCb, $array), but it would make sense to have them explicitly for clarity of the reader of the code.
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. Best regards Tim Düsterhus
