Re: [VOTE] PHP\iterable\any() and all() on iterables

On Mon, Feb 8, 2021, at 12:02 PM, tyson andre wrote: > Hi Larry Garfield, > > > > Hi internals, > > > > > > Voting has started on > > > https://wiki.php.net/rfc/any_all_on_iterable and > > > ends on 2021-02-22. > > > > > > This RFC proposes to add the functions `PHP\iterable\any(iterable > > > $input, ?callable $callback = null): bool and > > > PHP\iterable\all(...)` > > > to PHP's standard library's function set, using the namespace preferred > > > in the previous straw poll. > > > > > > There is a primary vote on whether to add the functions, and a > > > secondary vote on the name to use within the PHP\iterableëæõ÷¿&Fn > > > ±_c>мœ namespace. > > > > > > Thanks, > > > - Tyson > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > > Ak!  I literally just finished reading it and wanted to note a lack of clarity on one > > point. :-) > > > > The signature of the callback is never specified explicitly.  The ternary is a bit > > confusing.  I assume the signature is > > > > callable(mixed): bool > > > > But that's not made explicit.  It's also not made explict that omitting the > > callable collapses to "is truthy".  That's a sensible thing to do, but it's not > > stated explicitly anywhere, just inferred from the code sample. > > > > I'm not sure if it's safe to clarify at this point as the vote just started. > > If there is a callable, it allows callable(mixed): mixed, > and converts the callable's return value to a boolean. > So omitting the callable is the same as passing in the callable `fn($x) > => $x, which is equivalent to fn($x) => (bool)$x`. > This is exactly what the reference implementation would do. > > I definitely should have clarified it instead of assuming that the > reference implementation was clear enough. > > I clarified this and gave examples because the RFC started a few hours > ago and the implementation didn't change. Oof. I'm glad I asked, because I don't like that at all. If available, the callable should be returning bool, not "anything that may be truthy/falsy." If you have an explicit function, it should have an explicit return type. A truthy check is a reasonable default, but not for when you're opting in to specifying the logic. I am in favor of the RFC, but I will have to consider if that changes my vote to No. --Larry Garfield