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

Hi Mike Schinkel, > Doesn't the occasional required use of long constant names like ARRAY_FILTER_USE_KEY and > ARRAY_FILTER_USE_BOTH somewhat negative the benefit of a more concise syntax? > > I know that many existing functions in PHP have a collection of long constant names that can be > passed, but is that a style of programming that PHP really wants to continue to proliferate, or > would it not be better to address that use-case in a different manner? (Admittedly doing so might > require having this feature dependent on other critical path language features.) > > One approach might be if PHP could allow for skipped parameters in callables — where I am > using a single underscore to indicate an unused parameter (GoLang has a "blank identifier" > for similar purposes so there is some prior art to consider) — e.g: > > - the default is any($iterable, fn ( $value ) => ...) > - or any($iterable, fn ( _, $key ) => expr ) > - or any($iterable, fn ( $value, $key ) => expr ) > > PHP could handle it more generically, is possible, or recognize this and branch to different > implementations of any() and all() if the goal is to optimize performance by only passing one value > in key-only or value-only calls. > > Optionally we could use null instead: > > - the default is any($iterable, fn ($value) => ...) > - or any($iterable, fn (null, $key) => expr ) > - or any($iterable, fn ($value, $key) => expr ) Supporting "blank identifiers" is out of the scope of this RFC, and would have some implementation concerns of how it'd work with named parameters and how backtrace generation would be affected. I don't think there'd be a significant performance improvement over not using parameters. I'm taking $flag out of the rfc because there's many proposed alternatives for doing this, and checking values of an iterable is the most common use case. Repeating the response to Marco Pivetta, I find that checking parameter counts would be inconsistent with how other internal functions accepting callbacks such as array_filter already behave. It would also be unexpected if users or tooling wrap callbacks with other callbacks. Developers would also expect func_get_args() to work. ``` <?php function my_none(iterable $values, callable $predicate) { return all($values, fn(...$args) => $predicate(...$args)); } // PHP can't distinguish between these when given fn(...$args) // - would throw if passed 1 parameter my_none($values, fn($value, $key) => $value == true || $key == 'x'); // - would throw if passed 2 parameters (too many) my_none($values, 'is_string'); ``` Cheers, - Tyson