> On Aug 30, 2020, at 12:31 PM, tyson andre <tysonandre...@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?
