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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
