Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123246
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-416-g2c1796742e-fm-20240424.001-g2c179674
Precedence: bulk
MIME-Version: 1.0
Message-ID: <60bb55a5-16c9-4df0-8521-75f82d3dbf5b@app.fastmail.com>
In-Reply-To: <45e6365b-4963-4969-8cc1-80bae6922fc8@wcflabs.de>
References: <24e4529d-0b75-44de-90ef-34de5dfb1c99@wcflabs.de>
 <278889be-82ab-4827-a9e7-801b5ba2d8f8@app.fastmail.com>
 <CAAKU0ukwfF+D5L+23BEqL053ktCp5AQOjRGdha-8pXN-yf1HBQ@mail.gmail.com>
 <06373f2b-5de0-4582-96c5-29c3b474c01d@wcflabs.de>
 <45e6365b-4963-4969-8cc1-80bae6922fc8@wcflabs.de>
Date: Wed, 01 May 2024 10:26:19 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC [Discussion]: array_find
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 23, 2024, at 7:53 PM, Joshua R=C3=BCsweg wrote:
> Hi
>
> On 19.04.24 21:20, Joshua R=C3=BCsweg wrote:
>> I definitely see the point where there is an advantage to having two=20
>> separate methods and can definitely understand that it is easier for=20
>> developers to understand the control flow without evaluating the=20
>> parameters.
>>=20
>> I'm unsure if that's really necessary though, because basically it's=20
>> probably not necessary to directly see what exactly the function=20
>> returns. Perhaps there will be another opinion on this in an email in=20
>> the next few days.
>
> Now that I've thought about it for a few days, it's really better that=20
> the whole thing is broken down into two methods. I have adjusted the R=
FC=20
> accordingly. The RFC contains now two separat functions `array_find` a=
nd=20
> `array_find_key`.
>
> Cheers
>
> Josh

This looks good to me, with one remaining exception, which isn't specifi=
c to this function but should still be discussed: Always passing the val=
ue 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 argumen=
t.  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 (ei=
ther short or long form), but are still hidden landmines for anyone usin=
g 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 o=
f the function that pass one or two arguments.  I don't think that's a g=
ood answer for this RFC, but I'm not sure what is.  At the very least, i=
t should be mentioned as a known-limitation that gets documented., unles=
s we can come up with something better.

--Larry Garfield