RFC [Discussion]: array_find View as Markdown

Hi

I feel the same. Adding an enum for each binary parameter that is
semantically true and false feels quite unwieldy with how class / enums
/ interfaces are currently organized in the namespace hierarchy.

Point of order: This parameter is not semantically true and false. It is semantically either/or, and we kinda twist sideways to make it look like true/false if we squint. That's actually pretty common in the current stdlib, though it's not a good approach. Hence why I asked about an enum. I wouldn't expect it to be single-function, though, but to be applicable for multiple functions. (I did not go looking to see if such functions exist.)

Whoops, I accidentally a word in that paragraph, thank you.

It should have read "each binary parameter that is NOT semantically true
and false".

Best regards
Tim Düsterhus

Hi

Another alternative is to always return the key, because you can trivially get the value from the key, but not vice versa. Of course, the resulting syntax for that is frequently fugly.

$val = $array[array_find($db, $array)] ?? some-default;

In 95% (roughly) of cases, I (personally) need the array value and not
the key. Just having the option to get the key is already a step forward
compared to the current state, but I personally would find it
impractical (and fugly, as you said) to use the method, especially if
the search callback is more complex and multi-line (and it is fugly, as
you said).

Here is an example for this, without using a helper variable:

$value = $array[\array_find($array, function ($value, $key): bool {
if ($key % 5) {
return \strlen($value) < 100;
}

 if ($key % 2) {
     return \strlen($value) < 40;
 }

 return false;

})];

So I think, this is not an option.

Cheers

Josh

Hi

On 19.04.24 23:29, Tim Düsterhus wrote:> Thinking about this: I believe
that it would make sense to bundle

array_any and array_every (or array_all, see below) within the same RFC
due to the similarity. It can be a separate vote for those two, but
having the option of getting all three would probably alleviate my
concerns of adding new array functions piecemeal.

The implementation should be trivial, because it effectively just
changes the return type. Nevertheless I'm happy to assist should any
issues arise.

As for the naming:

JavaScript: every      + some
Haskell   : all        + any
Rust      : all        + any
C++       : all_of     + any_of + none_of
Java      : allMatch   + anyMatch (in java.util.stream.Stream)
Swift     : allSatisfy + contains(where: …)

It appears the commonly used choice is all + any.

Thanks for your suggestion! I have added the array_any and array_all
functions to the RFC accordingly.

Cheers

Josh

Hi

I definitely see the point where there is an advantage to having two
separate methods and can definitely understand that it is easier for
developers to understand the control flow without evaluating the
parameters.

I'm unsure if that's really necessary though, because basically it's
probably not necessary to directly see what exactly the function
returns. Perhaps there will be another opinion on this in an email in
the next few days.

Now that I've thought about it for a few days, it's really better that
the whole thing is broken down into two methods. I have adjusted the RFC
accordingly. The RFC contains now two separat functions array_find and
array_find_key.

Cheers

Josh

The RFC looks better to me. The
Unaffected PHP Functionality section looks like it needs
updating, though:

This RFC only adds two new functions and an enum to PHP and
only affects previously defined functions which are named as
the proposed function or enum.

I don't see an enum in the text nor in the git diff.

Hi

I definitely see the point where there is an advantage to having two
separate methods and can definitely understand that it is easier for
developers to understand the control flow without evaluating the
parameters.

I'm unsure if that's really necessary though, because basically it's
probably not necessary to directly see what exactly the function
returns. Perhaps there will be another opinion on this in an email in
the next few days.

Now that I've thought about it for a few days, it's really better that
the whole thing is broken down into two methods. I have adjusted the RFC
accordingly. The RFC contains now two separat functions array_find and
array_find_key.

Cheers

Josh

This looks good to me, with one remaining exception, which isn't specific to this function but should still be discussed: Always passing the value and key to the callback is unsafe, for two reasons.

1. If the callback is an internal function rather than a user-land one, and it has only one argument, it will error confusingly. That makes the current implementation incompatible with unary built-in functions. See, for instance, https://www.php.net/is_string (and friends)

2. If the callback takes two arguments but the second is optional, it's highly unlikely that the key is the value expected as the second argument. This could lead to confusingly hilarious errors. See, for instance, https://www.php.net/intval.

These won't come up in the typical case of passing an inline closure (either short or long form), but are still hidden landmines for anyone using functions not tailor made for these functions.

I'm not sure of a good solution here, honestly, so I don't know what to recommend. In Crell/fp, I ended up just making two different versions of the function that pass one or two arguments. I don't think that's a good answer for this RFC, but I'm not sure what is. At the very least, it should be mentioned as a known-limitation that gets documented., unless we can come up with something better.

--Larry Garfield