Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114483
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_34026298-AFFA-418A-BE2B-D02994CF020C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 14 May 2021 20:17:55 -0500
References: <f3d20496-c560-42b7-9a0d-8672b3cafa7d@www.fastmail.com>
 <1565EB81-57B7-49B0-A47C-342E0088A432@trowski.com>
 <CAN2symhHys1uADWnOfraEA3SiM8_57=JttWhgOJ0Kh7nwt4R+g@mail.gmail.com>
 <532D1413-52FF-4403-A20B-BBDB51163C85@trowski.com>
 <77e233b3-8046-4992-83e4-675d26712091@www.fastmail.com>
 <4F5C67CA-9079-4BFE-9786-3CB307E2138A@trowski.com>
 <c5059a7b-8b7e-4543-988e-a92c1d2086a7@www.fastmail.com>
To: php internals <internals@lists.php.net>
In-Reply-To: <c5059a7b-8b7e-4543-988e-a92c1d2086a7@www.fastmail.com>
Message-ID: <A623BDD7-91D6-409E-8068-B8DE5E86377C@trowski.com>
Subject: Re: [PHP-DEV] [RFC] Partial function application
From: aaron@trowski.com (Aaron Piotrowski)

--Apple-Mail=_34026298-AFFA-418A-BE2B-D02994CF020C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On May 14, 2021, at 7:36 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote:
>>=20
>>> On May 14, 2021, at 7:00 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>>>=20
>>> Is that actually going to come up?  Given that PHP functions (at =
least user-space ones) accept extra trailing arguments and just let them =
fall off, I would *expect* a closure that way to do the same.  Named =
arguments continue that, I believe, by just ignoring any variadic =
arguments that do not match a parameter in the function.  It seems odd =
to go back on that behavior now.
>>=20
>> I don't consider forwarding extra arguments an issue. I briefly was=20=

>> thinking it might be nice to be explicit about the number of =
arguments=20
>> a partial would accept, but you convinced me otherwise in R11, so I=20=

>> think we're on the same page here.
>>=20
>>>=20
>>> I can't speak for the others, but I could tolerate making "more than =
one extra ? beyond the end of the parameter list is an error", =
potentially, as at that point they're redundant.  But if a function has, =
say, 4 params, then fourParams(1, 3, ?) is a convenient way to say "and =
placeholder everything else".  Especially in dynamic cases like Nicolas =
pointed out, you may not necessarily know how many arguments there are.
>>=20
>> With what I proposed in my last email, `fourParams(1, 3, ?)` is=20
>> acceptable, there's nothing superfluous there. At least one ? is =
needed=20
>> to declare a partial. Similarly, a partial for a no parameter =
function:=20
>> `$partial =3D functionTakingNoParams(?)`. Or even a partial with args=20=

>> bound to all four params: `fourParams(1, 2, 3, 4, ?)`.
>>=20
>> What would error is `fourParams(1, 3, ?, ?)`, as the second ? is =
meaningless.
>>=20
>> I think you've convinced me that one-for-one matching on ? is=20
>> burdensome, but the above is a happy medium perhaps?
>=20
> I'd be OK with "no more than one trailing ? in excess of what the =
underlying callable has."  (Which means if you don't know, just stick =
one ? at the end and you know it will work.)

I think multiple trailing ? should be an error, otherwise how am I =
suppose to know at a glance if a partial declaration will error? Plus =
it=E2=80=99s adding multiple ways to declare the same thing, which I was =
hoping to avoid.

fourParams(1, 2, ?); // OK
fourParams(1, 2, ?, ?); // OK for you, should error to me
fourParams(1, 2, ?, ?, ?); // Again OK for you, should error to me
fourParams(1, 2, ?, ?, ?, ?); // Error for both

What value is gained in allowing any of those but the first?

I=E2=80=99d also be fine allowing a trailing ? in any declaration. =
It=E2=80=99s unnecessary, but one could argue that it=E2=80=99s =
consistent to allow a trailing ? in any partial, since it=E2=80=99s =
required for some.

fourParams(?, 2, ?); // Could error, but probably fine for consistency

Aaron Piotrowski=

--Apple-Mail=_34026298-AFFA-418A-BE2B-D02994CF020C--