Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

This is only part of a thread. view whole thread
  105282
April 15, 2019 11:24 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-14 kl. 18:52, skrev Nikita Popov:
> On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov ppv@gmail.com> wrote: > >> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov ppv@gmail.com> wrote: >> >>> Hi internals, >>> >>> Motivated by the recent list comprehensions RFC, I think it's time we >>> took another look at short closures: >>> >>> https://wiki.php.net/rfc/arrow_functions_v2 >>> >>> This is based on a previous (withdrawn) proposal by Levi & Bob. It uses >>> the syntax >>> >>> fn($x) => $x * $multiplier >>> >>> and implicit by-value variable binding. This example is roughly >>> equivalent to: >>> >>> function($x) use($multiplier) { return $x * $multiplier; } >>> >>> The RFC contains a detailed discussion of syntax choices and binding >>> modes. >>> >>> Regards, >>> Nikita >>> >> Heads up: I plan to start voting on this RFC tomorrow if nothing new comes >> up. >> >> Most of the discussion was (as expected) about the choice of syntax. >> Ultimately I think there are many reasonable choices we can make here, but >> we should stick to a specific proposal for the purposes of the RFC vote. >> None of the given arguments convinced me that some other syntax is >> *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a >> matter of some choices being slightly better in one case and slightly worse >> in another. My personal runner-up would be \($x, $y) => $x*$y, but I >> suspect that there are some people who are more strongly biased against >> "sigil salad" than I am... >> >> Nikita >> > So, there's been quite a bit of extra discussion here... unfortunately I > can't say that it really clarified anything, we're still circling around > different syntax choices, with the main contenders being fn, \ and ==>. > > fn($x) => $x > fn($x, $y) => $x*$y > > \$x => $x > \($x, $y) => $x*$y > > $x ==> $x > ($x, $y) ==> $x*$y > > I think the main qualities of these possibilities are: > > * Implementation complexity: fn and \ are easy, ==> is hard (lexer hack). > * Availability of reduced syntax: \ an ==> have a special single-argument > syntax, fn doesn't. > * Obviousness/readability: fn and ==> are obvious, while \ is not. > Especially \$x => $x looks quite obscure to the uninitiated (is that a > variable escape, like it would be in strings?) > > At this point I'm considering to either a) move forward with fn() as the > choice I'd consider most likely to gather a consensus or b) have a > secondary three-way vote between these three syntax choices. > > Nikita Hi,
Even if a consensus wasn't reached I feel that there has been quite a constructive discussion, where the pros and cons were drilled down for the syntax alternatives at hand. So having no voting rights myself, but alternative B for voting looks ok in my eyes. One could ask having three alternatives or two? OTOH, those three alternatives are now on the table and nothing else, so all three. But if implementation of ==> are much to overwhelming, only two. r//Björn L
  105283
April 15, 2019 11:48 benjamin.morel@gmail.com (Benjamin Morel)
Even though I was originally hoping for something closer to JS syntax,
considering Nikita's summary it looks like the best contender is still
fn(), as originally proposed.
At least it looks like a function indeed, to the uninitiated.

So FWIW, I think that a vote for the fn() syntax only still makes sense.
The risk with the 2 or 3 options is never being able to reach a concensus:
is a relative majority or an absolute majority for one of the syntaxes
acceptable, or are you required by the RFC process to get a 2/3 majority
for this vote as well? If so, considering the discussion so far, I think
this will be hard to achieve with 2 choices, let alone with 3.

- Ben
  105285
April 15, 2019 12:04 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-15 kl. 13:48, skrev Benjamin Morel:
> Even though I was originally hoping for something closer to JS syntax, > considering Nikita's summary it looks like the best contender is still > fn(), as originally proposed. > At least it looks like a function indeed, to the uninitiated. > > So FWIW, I think that a vote for the fn() syntax only still makes > sense. The risk with the 2 or 3 options is never being able to reach a > concensus: is a relative majority or an absolute majority for one of > the syntaxes acceptable, or are you required by the RFC process to get > a 2/3 majority for this vote as well? If so, considering the > discussion so far, I think this will be hard to achieve with 2 > choices, let alone with 3. > > - Ben
If it lands in a secondary three way vote I would assume it's the vote getting the most votes. Otherwise the RFC could land in a limbo, getting yes on feature but no on syntax. Good to get assumption confirmed though... r//Björn L
  105311
April 17, 2019 14:03 larry@garfieldtech.com ("Larry Garfield")
On Mon, Apr 15, 2019, at 6:48 AM, Benjamin Morel wrote:
> Even though I was originally hoping for something closer to JS syntax, > considering Nikita's summary it looks like the best contender is still > fn(), as originally proposed. > At least it looks like a function indeed, to the uninitiated. > > So FWIW, I think that a vote for the fn() syntax only still makes sense. > The risk with the 2 or 3 options is never being able to reach a concensus: > is a relative majority or an absolute majority for one of the syntaxes > acceptable, or are you required by the RFC process to get a 2/3 majority > for this vote as well? If so, considering the discussion so far, I think > this will be hard to achieve with 2 choices, let alone with 3. > > - Ben
I don't think the wiki currently supports it, but that's exactly what ranked choice voting is for. :-) --Larry Garfield