Re: Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

> I like this, but I do not like the flags.  I don't think they're at all useful.  A > lot of the other discussion in the thread seems to be needlessly complicating it, too. >  > all() and any() only need return booleans.  Their callbacks only need return booleans.  > That's the point.  first() makes sense to add, and it would return the first value that > matches. What would first() return on failure? Would it throw (inefficient)? Would it set an optional output reference to distinguish between returning the value null from an iterable and the null from no matches? An alternative use for a global function called first() would be to simply return the first element of an iterable, similar to the proposed array_value_first for arrays > For the callback itself, there is work to, hopefully, add partial function application to > 8.1.  (No idea if it will be successful, but the effort is in progress.)  If so, the upshot is > that turning an arbitrary function into a single-parameter function becomes silly easy, which means > functions like this can just expect a single parameter callback and be done with it.  No need for > extra-args or flags or whatnot. > If you want to check the keys of an array, call array_keys() first and use that. > > if (any(array_keys($foo), fn($k) => $k %2)) { ... } That doesn't work for a predicate on the keys of a generator, e.g. if you want to stop calling the generator once the short-circuiting happens. And there are occasionally situations where the predicate depends both on the key and the value any($itemMap, fn($enabled, $itemId) => $enabled && meetsAdditionalCondition($itemId), ARRAY_FILTER_USE_BOTH) Still, since there's debate over whether to even complicate this by filtering by key, and what the best way is to implement filtering by key, I'll probably take out the int $flag = 0 part from the initial RFC. Those can be added in subsequent RFCs. Thanks, - Tyson