Re: Re: [RFC] Arrow functions / short closures

Den 2019-04-14 kl. 18:52, skrev Nikita Popov:

On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov <nikita.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 again , I came to think on BC impact of fn() syntax. The RFC mentions 12 matches and 1 in namespaces. Should one conclude that the BC impact is low or is their other aspects to consider? I myself uses fn as a dummy function name when writing "test" code. r//Björn L