Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123252
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: <7a77288e-ddb7-436e-8981-b8b2508e1547@app.fastmail.com>
In-Reply-To: <41ad56d9-8b27-420e-ba85-a3e9a6122bcf@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>
 <60bb55a5-16c9-4df0-8521-75f82d3dbf5b@app.fastmail.com>
 <41ad56d9-8b27-420e-ba85-a3e9a6122bcf@wcflabs.de>
Date: Thu, 02 May 2024 13:27:29 +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 Wed, May 1, 2024, at 9:26 PM, Joshua R=C3=BCsweg wrote:
> Hi
>
> On 01.05.24 12:26, Larry Garfield wrote:
>> This looks good to me, with one remaining exception, which isn't spec=
ific to this function but should still be discussed: Always passing the =
value and key to the callback is unsafe, for two reasons.
>>=20
>> 1. If the callback is an internal function rather than a user-land on=
e, 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)
>
> I think, that this problem can easily be detected with static analyser=
s.=20
> Currently neither PHPStan [1] nor psalm [2] does detect this issue, bu=
t=20
> as the tools already validate the signature (e.g. str_contains is=20
> rejected) this can probably be integrated and might even be considered=
 a=20
> bug.
>
> The proper fix from PHP's side would be something like the proposal in=20
> https://externals.io/message/122928 (RFC idea: using the void type to=20
> control maximum arity of user-defined functions).

It's not just that it errors confusingly.  It's that the design as is wo=
uld be incompatible with any C-based function.  A function that works wi=
th anything *except* the standard library seems... problematic.

It's possible that, since these new functions are C-based, we could do s=
ome extra detection to see if the function is unary or not, and pass onl=
y the value if it is.  I don't know if that is possible to do performant=
ly in C, but it's definitely more of an option than if they were in user=
-space.  (Again, I don't know if this is the best solution, but it seems=
 like a possible solution.)

--Larry Garfield