Den 2019-04-14 kl. 18:52, skrev Nikita Popov:
On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov <nikita....@gmail.com> wrote:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov <nikita....@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
