On Mon, Oct 22, 2018 at 1:39 AM Levi Morrison <levim@php.net> wrote:
>
> On Sun, Oct 21, 2018 at 10:04 PM bugreportuser
> <bugreportuser+php.internals@gmail.com> wrote:
> >
> > Hi everyone,
> >
> > A patch for array_every() and array_any() was abandoned from inactivity,
> > so I wrote a new patch for it:
> >
> > https://github.com/php/php-src/pull/3597
> >
> > There was never an internals@ discussion that I can find, but there are
> > some comments on the old pull request. Most of what I changed was not
> > including a traversable type in the same patch, since
> > https://bugs.php.net/bug.php?id=76865 was opened.
> >
> > Any thoughts/comments?
> >
> > Thanks
>
> I think this is too small in scope, but...
I've seen it come up more than expected. Sometimes not as a function:
https://git.io/hfclelde
https://git.io/304ffwgx
https://git.io/8fsbhqvw
https://git.io/bz4c9bgq
It can also help for validating array arguments.
> I there is some point where we should have a standard library v2.0
> which incorporates the years of improvements in the language and
> experience gained to produce a better experience. I don't think we're
> there yet. Some features that might put us there:
>
> - Generics and callable type signatures e.g.
> function transform<T, U>(callable(T): U $transformer, iterable<T>
> $input): iterable<U>;
> - Named parameters or parameter labels e.g.
> sorted($iterable, compare: greater_than())
>
> As things are now I don't think the end result would be better by
> enough to warrant the effort and disruption into the ecosystem.
>
> So tying this back to the proposal: I think it's best to wait.
It's not important but many other languages have it. It prevents adding
the same simple functions to many projects. It also fits with
array_sum() and array_product() which can also be implemented using
array_reduce().
I think these are helpful to add since v2.0 will probably not happen
soon. However, I don't have a problem closing the pull request if that's
that's the decision.
