On Tue, Apr 23, 2024, at 7:53 PM, Joshua Rüsweg wrote: > Hi > > On 19.04.24 21:20, Joshua Rüsweg wrote: >> 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
