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

> On Aug 30, 2020, at 12:31 PM, tyson andre <tysonandre775@hotmail.com> wrote: > > 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. Acknowledged. If not a significant performance improvement why not pass both value and key to the callable in your RFC in case someone needs access to the key? Adding the key as a second parameter would not preclude passing a flag to modify behavior in a future version of PHP if that is the internals consensus. -Mike P.S. John Bafford recently suggested the use of void in foreach loops for essentially the same reason as I proposed with underscore or null (and frankly void is better than underscore or null): https://externals.io/message/111774 <https://externals.io/message/111774> If his RFC were to pass then that would open the door to using it here, right?