Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114579
MIME-Version: 1.0
References: <CAF+90c_iYjsDWoqPaDtavVgj2WFdpiuBmGeQZFAqokVoVZTxoA@mail.gmail.com>
 <CALfTnfXDTvrtA9-hN+UH+qs3iS9q34jseunBD7YumGkonrSwXA@mail.gmail.com>
 <CAF+90c9DpTWzqu9S9=CkuaW=RnbneXUbRbqhuJDRBPwUz9RMsA@mail.gmail.com>
 <CAC5V6ghco1H4jT2Y_ug3LTWfyAz_5f6iCObGrdDfXn2PeuXgLg@mail.gmail.com>
 <fa269b69-9bac-4a81-8c65-409766f1c9f8@www.fastmail.com> <CAOWwgp=QZ0jAy4Qc+w7grEEN0b9KCX+Uec12AQoYPQHTqQ-Ddg@mail.gmail.com>
 <CAOWwgpmQeN9J9pTOenTrSngzWAN_P6XRf4Z1CNrSmDFGHjtsRg@mail.gmail.com> <13cb59de-f335-4532-9e7a-400499661dbf@www.fastmail.com>
In-Reply-To: <13cb59de-f335-4532-9e7a-400499661dbf@www.fastmail.com>
Date: Tue, 25 May 2021 12:31:01 +0200
Message-ID: <CAOWwgpn-Q+Xry2hxqvsBu3cQ9YRNPLj++zJ1fVwwkNKkH=3jmg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076936205c32506c6"
Subject: Re: [PHP-DEV] [RFC] First-class callable syntax
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000076936205c32506c6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le ven. 21 mai 2021 =C3=A0 16:31, Larry Garfield <larry@garfieldtech.com> a
=C3=A9crit :

> On Fri, May 21, 2021, at 2:52 AM, Nicolas Grekas wrote:
> > Sorry for self-reply, this needs some clarifications :)
> >
> > Le ven. 21 mai 2021 =C3=A0 09:17, Nicolas Grekas <
> nicolas.grekas+php@gmail.com>
> > a =C3=A9crit :
>
>
> > >> There's been a lot of rapid iteration, experimentation, and rejectio=
n.
> > >> The most recent alternatives are this one from Levi:
> > >>
> > >> https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbf=
d
> > >>
> > >> And this one from me:
> > >>
> > >> https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8
> > >>
> > >> The main takeaways (to give context to Nikita's proposal):
> > >>
> > >> * Because of optional arguments, using the same symbol for "copy one
> > >> parameter from the underlying function" and "copy all remaining
> parameters
> > >> from the underlying function" is not viable.  It runs into oddball
> cases
> > >> where you may intend to only use one argument but end up using
> multiple,
> > >> especially in array operation functions that sometimes silently pass
> keys
> > >> along to callbacks if they can.  Hence the separate ? and ... that
> were
> > >> proposed.
> > >>
> > >
> > > I've read that some ppl think this should be fought, but that's
> actually a
> > > critical feature of the engine when writing BC layers by adding extra
> > > arguments via this possibility.
> > >
> >
> > I'm talking about implicit extra arguments accessed via func_get_args()
> > here.
>
> The issue is with optional arguments that would get auto-forwarded, even
> when you don't want to use them.  (It wasn't obvious to me for a long tim=
e
> that this issue existed either.)  The classic example, ported from
> Javascript:
>
> function printInt(string $value, int $base =3D 10): void
> {
>     echo intval($value, $base), "\n";
> }
>
> $array =3D ['10', '10', '10', '10', '10'];
>
> array_walk($array, 'printInt');
>
> Results in:
>
> 10
> 0
> 2
> 3
> 4
>
> The function has multiple arguments, but we only want to use one, but
> functions like array_walk() will try to use  the optional one if they
> can... even if doing so makes no logical sense.  Having ? capture all
> arguments unconditionally would also mean it captures optional arguments
> even if you don't want it to.  That's why we need to have the separate ..=
.
> symbol for when you really do mean "and all the rest".
>

Got it thanks. Makes sense to me now.

In this case, we need printInt(?) to only pass $value through.  If you
> really did want to use the array key for the base for some reason, you
> could do printInt(?, ?) or printInt(...).
>
> I think the plan would be that extra passed arguments to a partialed
> function would still forward through, but that may end up being more
> difficult than expected.
>
> > In the 2nd gist, I read "If the current position is a ..., copy all
> > > remaining parameters from the underlying function, including a
> variadic."
> > > But to me it's important that all extra arguments are forwarded to th=
e
> > > partialized callable, where ... is used or not.
> > > Please clarify this point if possible.
>
> I think this is the same as the previous question?
>
> (Note that several vocal people have argued that the way PHP passes along
> extraneous arguments is a bug, not a feature.  I don't have a strong
> feeling about it, but some do.)
>

Being vocal doesn't mean being right :)
This feature of the language is critical to write BC layers, see eg this,
LSP rulez:
https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Form/Choi=
ceList/Factory/ChoiceListFactoryInterface.php#L38

It has to stay (unless an alternative is provided of course.)


> > * Named arguments make things more complicated.  One of the questions i=
s
> > >> whether named placeholders should be supported or not.  And if they
> are,
> > >> does that mean you can effectively reorder the arguments in the
> partial
> > >> application, and what does that mean for usability.  It gets
> complicated
> > >> and scope-creepy fast.
> > >>
> > >
> > > For the userland pov, the principle of least surprise would say we
> should
> > > answer yes to both questions.
> >
> > Reading your gists, I'm with drawing this expectation.
> >
> > Since calls reorder named arguments automatically, we could expect the
> same
> > for PFAs.
> > That is:
> > since foo(A: 1, B: 2) is exactly the same as foo(B: 2, A: 1)
> > we could also expect that foo(A: ?, B: ?) would be exactly the same
> > foo(B:?, A:?)
> >
> > The issue here is that the syntax can be interpreted as both a new
> > signature and as a partial call.
> > If we stay pure to the intend of PFAs, argument reordering shouldn't be
> > allowed IMHO. Aka this should be interpreted only as a partial call.
> >
> > *If* we need a way to reorder arguments, I think it would be natural al=
so
> > to be able to *rename* arguments.
>
> Which is also where the rabbit hole gets extra deep, and why I am
> perfectly happy to just disallow named placeholders.  In the rare use cas=
es
> where you really do want/need to reorder arguments and do other esoteric
> things, short lambdas already let you do that much more explicitly.  That=
's
> an edge case that already has a solution.  We're focused here on making t=
he
> most common cases nicer.
>
> > That's where my syntax proposal based on short closures might be handy:
> >
> > fn($a, $b, ...) =3D> $callable($b, a: $a, ...)
>
> At that point we're not getting any benefit over just using arrow
> functions.  The point of PFA is that it's partially calling a function
> as-is, in a compact way.  That in PHP we'd be implementing it as
> yet-another-closure object is an implementation detail.
>

And the point of PFA is also to copy the existing signature, which is a
significant difference with short closures.
This completely disqualifies my proposal :)
But this also highlights a critical reason for adding PFAs: they're not
only syntax sugar to write short closure, but an abstraction over the
signature of partialized callables!

Last proposal, just to be sure we screened them all: using "...?" instead
of "..."
$callable(...?)




> > >> We also went down a rabbit hole of trying to make argument reorderin=
g
> > >> work because some people asked for it, but as noted that's a very de=
ep
> > >> rabbit hole.
> > >>
> > >
> > > Then maybe named args should be forbidden for "?" placeholders. This
> would
> > > keep this possibility open of the future and close the "principle of
> least
> > > surprise" expectation if there are. Aka foo(bar: ?) should be a parse
> error
> > > for now at least.
>
> That is precisely the conclusion I reached and what my writeup says: The
> only placeholders are positional placeholders.  Named arguments are fine,
> but not named placeholders.
>
> > > My own take is that the PFA discussion has been overly-bikeshedded,
> which
> > >> is unfortunate since I think we're quite close to now having a
> workable
> > >> answer that covers most reasonable use cases.  While I agree Nikita'=
s
> RFC
> > >> here would be an improvement over 8.0, I don't think throwing in the
> towel
> > >> on PFA yet is a good idea.  It's a much more robust and powerful
> approach
> > >> that still gets us the "first class callable" syntax we all want (at
> least
> > >> I assume we all do), and lots of additional power to boot.  I'd
> rather see
> > >> us try to drive PFA home to completion.  If that proves impossible b=
y
> early
> > >> July, then this RFC would still get us something this cycle, as long
> as the
> > >> syntax is still compatible with PFA.  (Otherwise whenever PFA gets
> sorted
> > >> out in the future we end up with yet-more-ways to do the same thing
> that
> > >> are not optimizations of each other but just competing syntax, in
> which
> > >> case no one wins.)
> > >>
> > >
> > > I agree. Let's figure out PFAs!
> > >
> > > If I may add to the bikeshedding, and since PFAs are like others said
> > > "short lambas on steroids", what about borrowing the syntax from them=
?
> > >
> > > Here would be the first-class callable syntax:
> > >
> > > fn(...) =3D> $callable(...)
> > >
> > > and for PFAs:
> > >
> > > fn(...) =3D> $callable(?, 42, ...)
> > >
> > > Nicolas
>
> As above, not really viable.
>
>
> Also, to answer Andreas as long as I'm here: Supporting "new Foo" with PF=
A
> is a separate question.  As noted in the currently written draft of the
> RFC, the problem is that object creation is not a function call; the obje=
ct
> is created, then the __construct initializer is called.  A naive PFA
> implementation would therefore create the object once, couple it to the
> partial, and then calling the partial repeatedly would return the same
> object, rather than repeatedly making a new object.  Joe already figured
> out how to special case that, though, so it's a non-issue.
>
> Both Levi's writeup and mine could support PFA constructors, AFAIK.
>
> --Larry Garfield
>

Nicolas

--00000000000076936205c32506c6--