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

[Mike Schinkel]

> On Feb 8, 2021, at 7:37 PM, Kamil Tekiela  wrote:
> 
> Hi Tyson,
> 
> Thanks for the RFC. I have to say that I like the core concept and the
> motivation behind it. However, let me explain why I voted No.
> 
> 1. As others have said I think that the scope is too small. If we are going
> to create that namespace then I would like to see more functions/classes in
> that namespace.
> 2. I don't like the name. I know the namespace might provide some guidance
> of what the function is, but namespaces are often imported. What we are
> left with in the code is then `any()`/`all()` that doesn't have a
> self-describing name. any_values is better but still doesn't describe the
> action that the function will take. I am a strong believer that methods and
> functions should be called with verbs which describe an action. e.g.
> search, filter, combine, merge, etc. There can always be exceptions but
> there should be a good reason to justify such an exception.

Having self-describing function names is a good policy for userland code.  
However, and piggybacking on what Larry Garfield just wrote, for language 
primitives that will be used often by many developers and that have analogues 
in other languages, having short names works well. 

By definition there are not tons of language primitives like these for 
developers to learn, at least not when compared to userland code, and their 
shortness empowers developers to write more concise code.

-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Larry Garfield]

On Mon, Feb 8, 2021, at 6:37 PM, Kamil Tekiela wrote:
> Hi Tyson,
> 
> Thanks for the RFC. I have to say that I like the core concept and the
> motivation behind it. However, let me explain why I voted No.
> 
> 1. As others have said I think that the scope is too small. If we are going
> to create that namespace then I would like to see more functions/classes in
> that namespace.
> 2. I don't like the name. I know the namespace might provide some guidance
> of what the function is, but namespaces are often imported. What we are
> left with in the code is then `any()`/`all()` that doesn't have a
> self-describing name. any_values is better but still doesn't describe the
> action that the function will take. I am a strong believer that methods and
> functions should be called with verbs which describe an action. e.g.
> search, filter, combine, merge, etc. There can always be exceptions but
> there should be a good reason to justify such an exception.

The naming is fine, I think.  any(), all(), first(), etc. have long-standing 
meaning in multiple languages.  As long as we're using them consistently with 
convention I don't think there's any reason to introduce longer names, 
especially when, if done correctly, the stuff in this namespace would be highly 
chainable and give us a close-enough to comprehensions.  Short-sweet-but-clear 
is a good guideline on this one.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tyson andre]

Hi Guilliam Xavier,

> > > Hi Larry Garfield,
> > >
> > > > > 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.
> > > > > > >
> > > > > > > [...]
> > > > > >
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > >  [...] 
> > > > >
> > > > > 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.
> > > > >
> > > > >  [...] 
> > > >
> > > > 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
> > >
> > > This was a deliberate choice and is consistent with the weak type 
> > > comparison behavior of array_filter() and other functions that default to 
> > > using weak type checks internally.
> > >
> > > I'd agree that I'd prefer to see callbacks returning booleans in code I'm 
> > > reviewing,
> > > but a truthiness check seems more practical and consistent with the rest 
> > > of the language
> > > than throwing a TypeError or checking the predicate return value using 
> > > `!== true`
> > >
> > > This was made to make PHP more widely accessible and free of surprises.
> > > e.g. `(bool)array_filter($arr, $predicate)` can be safely converted to 
> > > `any($arr, $predicate)` without introducing a TypeError or behavior 
> > > change.
> > >
> > >  [...] 
> > 
> > For what it is worth, in C++ it is fairly normal to use a convertible
> > to bool type. For instance, having an overload on a < b for iterators
> > can return whatever type it wants, as long as it is contextually
> > convertible to bool.
> 
> Yet in 8.0, a non-[ 1 | 0 | -1 ] return from a comparison function as just 
> converted to a warning.  So the trend in the language seems to be the other 
> direction.
> 
> Are you referring to this frequent mistake?
> 
> ```
> $list = [2,4,1,3];
> usort($list, fn ($a, $b) => $a < $b); /* Deprecated: usort(): Returning bool 
> from comparison function is deprecated, return an integer less than, equal 
> to, or greater than zero */
> echo json_encode($list); // [4,3,2,1]
> ```
> 
> (That's probably because PHP user comparison functions were modelled from C 
> (e.g. strcmp()), not C++ (e.g. std::less).)
> 
> Of course here the "correct" thing is to return `$a <=> $b` (or `$b <=> $a` 
> for descending order), but you can also return `$a - $b` (not necessarily in 
> [-1,0,1]), or even a string `"foo"` still without any warning in 8.0.2 (just 
> a certainly wrong result)...

A callback function called **once** (before php 8.0) on a pair mapping 2 states 
(true, false) onto 3 states (-1, 0, 1) only worked coincidentally
because the sort wasn't stable. The desired type had more possible values than 
the returned type, so it did the wrong thing.
- This is different in that there's only 2 desired values.

https://wiki.php.net/rfc/stable_sorting fixed that calling it twice and 
deprecating booleans.
It still allows you to return strings (not likely in practice) and casts those 
to integers.

"Second, if boolean false is returned, PHP will automatically call the 
comparison function again with arguments swapped.
This allows us to distinguish whether the “false” stood for “equal” or “smaller 
than”. This fallback behavior should be removed in a future version of PHP."

> Anyway, to me it feels natural that any()/all() would "work" 

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

[Guilliam Xavier]

Hi,

On Tue, Feb 9, 2021 at 7:33 PM Larry Garfield 
wrote:

> On Mon, Feb 8, 2021, at 6:48 PM, Levi Morrison via internals wrote:
> > On Mon, Feb 8, 2021 at 5:15 PM tyson andre 
> wrote:
> > >
> > > Hi Larry Garfield,
> > >
> > > > > 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.
> > > > > > >
> > > > > > > [...] 
> > > > > >
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > >  [...]
> > > > >
> > > > > 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.
> > > > >
> > > > >  [...]
> > > >
> > > > 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
> > >
> > > This was a deliberate choice and is consistent with the weak type
> comparison behavior of array_filter() and other functions that default to
> using weak type checks internally.
> > >
> > > I'd agree that I'd prefer to see callbacks returning booleans in code
> I'm reviewing,
> > > but a truthiness check seems more practical and consistent with the
> rest of the language
> > > than throwing a TypeError or checking the predicate return value using
> `!== true`
> > >
> > > This was made to make PHP more widely accessible and free of surprises.
> > > e.g. `(bool)array_filter($arr, $predicate)` can be safely converted to
> `any($arr, $predicate)` without introducing a TypeError or behavior change.
> > >
> > >  [...]
> >
> > For what it is worth, in C++ it is fairly normal to use a convertible
> > to bool type. For instance, having an overload on a < b for iterators
> > can return whatever type it wants, as long as it is contextually
> > convertible to bool.
>
> Yet in 8.0, a non-[ 1 | 0 | -1 ] return from a comparison function as just
> converted to a warning.  So the trend in the language seems to be the other
> direction.
>

Are you referring to this frequent mistake?

```
$list = [2,4,1,3];
usort($list, fn ($a, $b) => $a < $b); /* Deprecated: usort(): Returning
bool from comparison function is deprecated, return an integer less than,
equal to, or greater than zero */
echo json_encode($list); // [4,3,2,1]
```

(That's probably because PHP user comparison functions were modelled from C
(e.g. strcmp()), not C++ (e.g. std::less).)

Of course here the "correct" thing is to return `$a <=> $b` (or `$b <=> $a`
for descending order), but you can also return `$a - $b` (not necessarily
in [-1,0,1]), or even a string `"foo"` still without any warning in 8.0.2
(just a certainly wrong result)...

Anyway, to me it feels natural that any()/all() would "work" like
array_filter().

@Tyson by the way, in the any()/all() case (vs the any_value()/all_values()
and potential any_key()/all_keys() etc.), wouldn't it be preferable to add
the optional `int $flags = 0` (or "$mode") parameter right from the start
(even if not used yet), as adding it in a later release would apparently
pose some BC concerns (ArgumentCountError, polyfills etc.)?

-- 
Guilliam Xavier

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

[Larry Garfield]

On Mon, Feb 8, 2021, at 6:48 PM, Levi Morrison via internals wrote:
> On Mon, Feb 8, 2021 at 5:15 PM tyson andre  wrote:
> >
> > Hi Larry Garfield,
> >
> > > > 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` 
> > > > > > 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
> >
> > This was a deliberate choice and is consistent with the weak type 
> > comparison behavior of array_filter() and other functions that default to 
> > using weak type checks internally.
> >
> > I'd agree that I'd prefer to see callbacks returning booleans in code I'm 
> > reviewing,
> > but a truthiness check seems more practical and consistent with the rest of 
> > the language
> > than throwing a TypeError or checking the predicate return value using `!== 
> > true`
> >
> > This was made to make PHP more widely accessible and free of surprises.
> > e.g. `(bool)array_filter($arr, $predicate)` can be safely converted to 
> > `any($arr, $predicate)` without introducing a TypeError or behavior change.
> >
> > ```
> > php > var_dump(array_filter([-1,0,1], fn($x)=>$x));
> > array(2) {
> >   [0]=>
> >   int(-1)
> >   [2]=>
> >   int(1)
> > }
> > ```
> >
> > This is the same choice as many other dynamic languages that aren't 
> > compiled ahead of time have made.
> >
> > ```
> > # python
> > >>> any([1])
> > True
> > >>> any([0])
> > False
> > # Ruby
> > irb(main):001:0> [nil].any?
> > => false
> > irb(main):002:0> [false].any?
> > => false
> > irb(main):003:0> !!0
> > => true
> > irb(main):004:0> [0].any?
> > => true
> > # JavaScript
> > > [0].some(x=>x)
> > false
> > > [1].some(x=>x)
> > true
> > ```
> >
> > It is currently possible to check if code is passing a callable returning 
> > anything other than a boolean
> > to functions such as `array_filter()` using a wide variety of static 
> > analyzers/tools, e.g. http://github.com/phan/phan
> >
> > ```
> >  > // Phan emits "PhanTypeMismatchArgumentInternal Argument 2 ($callback) is 
> > (fn) of type Closure(int):int
> > // but \array_filter() takes 
> > callable(mixed):bool|callable(mixed,mixed):bool"
> > array_filter([1], fn (int $x): int => $x % 3);
> > ```
> >
> > Thanks,
> > -Tyson
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> 
> For what it is worth, in C++ it is fairly normal to use a convertible
> to bool type. For instance, 

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

[Levi Morrison via internals]

On Mon, Feb 8, 2021 at 5:15 PM tyson andre  wrote:
>
> Hi Larry Garfield,
>
> > > 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` 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
>
> This was a deliberate choice and is consistent with the weak type comparison 
> behavior of array_filter() and other functions that default to using weak 
> type checks internally.
>
> I'd agree that I'd prefer to see callbacks returning booleans in code I'm 
> reviewing,
> but a truthiness check seems more practical and consistent with the rest of 
> the language
> than throwing a TypeError or checking the predicate return value using `!== 
> true`
>
> This was made to make PHP more widely accessible and free of surprises.
> e.g. `(bool)array_filter($arr, $predicate)` can be safely converted to 
> `any($arr, $predicate)` without introducing a TypeError or behavior change.
>
> ```
> php > var_dump(array_filter([-1,0,1], fn($x)=>$x));
> array(2) {
>   [0]=>
>   int(-1)
>   [2]=>
>   int(1)
> }
> ```
>
> This is the same choice as many other dynamic languages that aren't compiled 
> ahead of time have made.
>
> ```
> # python
> >>> any([1])
> True
> >>> any([0])
> False
> # Ruby
> irb(main):001:0> [nil].any?
> => false
> irb(main):002:0> [false].any?
> => false
> irb(main):003:0> !!0
> => true
> irb(main):004:0> [0].any?
> => true
> # JavaScript
> > [0].some(x=>x)
> false
> > [1].some(x=>x)
> true
> ```
>
> It is currently possible to check if code is passing a callable returning 
> anything other than a boolean
> to functions such as `array_filter()` using a wide variety of static 
> analyzers/tools, e.g. http://github.com/phan/phan
>
> ```
>  // Phan emits "PhanTypeMismatchArgumentInternal Argument 2 ($callback) is 
> (fn) of type Closure(int):int
> // but \array_filter() takes callable(mixed):bool|callable(mixed,mixed):bool"
> array_filter([1], fn (int $x): int => $x % 3);
> ```
>
> Thanks,
> -Tyson
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

For what it is worth, in C++ it is fairly normal to use a convertible
to bool type. For instance, having an overload on a < b for iterators
can return whatever type it wants, as long as it is contextually
convertible to bool.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Kamil Tekiela]

Hi Tyson,

Thanks for the RFC. I have to say that I like the core concept and the
motivation behind it. However, let me explain why I voted No.

1. As others have said I think that the scope is too small. If we are going
to create that namespace then I would like to see more functions/classes in
that namespace.
2. I don't like the name. I know the namespace might provide some guidance
of what the function is, but namespaces are often imported. What we are
left with in the code is then `any()`/`all()` that doesn't have a
self-describing name. any_values is better but still doesn't describe the
action that the function will take. I am a strong believer that methods and
functions should be called with verbs which describe an action. e.g.
search, filter, combine, merge, etc. There can always be exceptions but
there should be a good reason to justify such an exception.
3. I am unclear about the implementation itself. There aren't that many
clear examples in the RFC. For example, I don't understand why the second
parameter is nullable and optional. How is it different from array_filter?
4. Please, no more loose checks. I don't want to have the same trouble as
with `in_array()`.

Kind Regards,
Kamil

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

[tyson andre]

Hi Larry Garfield,

> > 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` 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

This was a deliberate choice and is consistent with the weak type comparison 
behavior of array_filter() and other functions that default to using weak type 
checks internally.

I'd agree that I'd prefer to see callbacks returning booleans in code I'm 
reviewing,
but a truthiness check seems more practical and consistent with the rest of the 
language
than throwing a TypeError or checking the predicate return value using `!== 
true`

This was made to make PHP more widely accessible and free of surprises.
e.g. `(bool)array_filter($arr, $predicate)` can be safely converted to 
`any($arr, $predicate)` without introducing a TypeError or behavior change.

```
php > var_dump(array_filter([-1,0,1], fn($x)=>$x));
array(2) {
  [0]=>
  int(-1)
  [2]=>
  int(1)
}
```

This is the same choice as many other dynamic languages that aren't compiled 
ahead of time have made.

```
# python
>>> any([1])
True
>>> any([0])
False
# Ruby
irb(main):001:0> [nil].any?
=> false
irb(main):002:0> [false].any?
=> false
irb(main):003:0> !!0
=> true
irb(main):004:0> [0].any?
=> true
# JavaScript
> [0].some(x=>x)
false
> [1].some(x=>x)
true
```

It is currently possible to check if code is passing a callable returning 
anything other than a boolean
to functions such as `array_filter()` using a wide variety of static 
analyzers/tools, e.g. http://github.com/phan/phan

```
 $x % 3);
```

Thanks,
-Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Larry Garfield]

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` 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tyson andre]

Hi Levi Morrison,

> > 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` namespace.
> >
> > Thanks,
> > - Tyson
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> 
> Thanks for the RFC. I have voted no, even though I am very supportive
> of the direction. My objections are:
> - I think the scope is too small. This is introducing a new family of
> functions, but is only proposing two functions. This is too small to
> firmly root in good design and precedence.

I misread your earlier comment in https://externals.io/message/111756#111764

My general stance on this is similar to 
https://github.com/Danack/RfcCodex/blob/4cb3466e42063be00ece0cdb296c0b1336eb81c0/rfc_etiquette.md#dont-volunteer-other-people-for-huge-amounts-of-work

I have limited time, and this has generated a lot of discussion.
I'm concerned that adding more functionality initially would add questions like 
"Do we really need to add `none()` if we already have `!any()` and
"I voted against this because I don't see the need for `chunk()`, `reversed()`, 
`filter()`, etc. (or disagree with one of the implementation details)"

> - I do not like the chosen namespace. This is not as important as the
> previous point, but still factored into my decision as we are still
> very early in choosing namespaces for internals. I don't want to vote
> for something I think is a bad direction when we're this early on.
> 
> Again, I am supportive of adding these functions in some form, but I
> very strongly do not believe this RFC is what we should do.

And you're strongly opposed to the global namespace. 
https://externals.io/message/112558#112598

An unrealistic hypothetical worst-case scenario would be where half of voters 
vote against 
any new categories of functions in the global namespace, and half of voters 
vote against
any new categories of functions outside of the global namespace, and nothing 
achieves a 2/3 majority
in php 8.1.

> I tried to collaborate with Tyson more on these points but either we
> mis-communicated or he wasn't interested. In any case, it's up for a
> vote so I choose "no."

I disagreed. 
My decision was based on 
https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace#vote
I strongly feel that this should be based on feedback from voters as a whole 
when we're this early in namespacing discussions,
or the namespacing discussion would continue as "maybe this was the wrong 
choice of namespace."

Thanks,
- Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tyson andre]

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` 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.

- Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Mark Randall]

On 08/02/2021 15:14, Kalle Sommer Nielsen wrote:

Den man. 8. feb. 2021 kl. 17.08 skrev Levi Morrison via internals
:

- I do not like the chosen namespace. This is not as important as the
previous point, but still factored into my decision as we are still
very early in choosing namespaces for internals. I don't want to vote
for something I think is a bad direction when we're this early on.


I am voting yes because the functionality is good and the namespace 
question was polled in advance using the fairest method available.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Kalle Sommer Nielsen]

Den man. 8. feb. 2021 kl. 17.08 skrev Levi Morrison via internals
:
> - I do not like the chosen namespace. This is not as important as the
> previous point, but still factored into my decision as we are still
> very early in choosing namespaces for internals. I don't want to vote
> for something I think is a bad direction when we're this early on.

I'm in a similar boat as Levi, I like the functionality but the
choosen namespace is what caused my no vote. We had 2 RFCs last year
talking about the namespace question and it is yet to be answered -- I
don't think this RFC or any other should go into the core as it could
force the answer to the namespace question. Having them in \ would be
a +1 from me tho.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Levi Morrison via internals]

On Mon, Feb 8, 2021 at 7:33 AM tyson andre  wrote:
>
> 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` namespace.
>
> Thanks,
> - Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Thanks for the RFC. I have voted no, even though I am very supportive
of the direction. My objections are:
- I think the scope is too small. This is introducing a new family of
functions, but is only proposing two functions. This is too small to
firmly root in good design and precedence.
- I do not like the chosen namespace. This is not as important as the
previous point, but still factored into my decision as we are still
very early in choosing namespaces for internals. I don't want to vote
for something I think is a bad direction when we're this early on.

Again, I am supportive of adding these functions in some form, but I
very strongly do not believe this RFC is what we should do.

I tried to collaborate with Tyson more on these points but either we
mis-communicated or he wasn't interested. In any case, it's up for a
vote so I choose "no."

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Larry Garfield]

On Mon, Feb 8, 2021, at 8:32 AM, tyson andre wrote:
> 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` 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.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php