Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104733 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42445 invoked from network); 15 Mar 2019 12:54:57 -0000 Received: from unknown (HELO mail-io1-f49.google.com) (209.85.166.49) by pb1.pair.com with SMTP; 15 Mar 2019 12:54:57 -0000 Received: by mail-io1-f49.google.com with SMTP id x9so7631755iog.12 for ; Fri, 15 Mar 2019 02:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kJCFmk9jHnIpAB2vt2GA6L7uZ/CI7Eh98lsiJ100CIE=; b=mR2p+YdlPAFLllu3YKJMaZxDwIXCICJOaSxK03D6v71hLaD1DdP4ux/gcEJqr/Mlxy /EMBk2vO7I9FuK287SscFrC9KdhKbhtqbu1UVhYRqmlu7BMfCumZGqlqgLDSAL7taUMw W1X/Zl6jawko822nTot1f3MNf7w26XR3xmFzrk741Xz7eA9bdjo4pVO4UNIUWJcsoDmT pNlz0t0QvwNhf89xgJm032P+VD6Mu5MRpXCkMvv9YDfS/vp5TyPkfQB9qHTwhV4LK0oh /Dod14wiSahmvXXE4Yf8mqlcqHPym5aTuBudUELQZaBq+b8yaLPa/7iUTPQPE3NmRgZl S9kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kJCFmk9jHnIpAB2vt2GA6L7uZ/CI7Eh98lsiJ100CIE=; b=SoKoSDMUr78o0vjnSO2U2HqIj5hj6wq3hiTeQgxYkM5WwT85eVQgM3ENNKj/sTpS8l Qo9wdwRikTjhIhLVU0zkkd/9BTzNVSD3BmaHkR4mmWMoklH6BjT/qYLKgjwo4LqHUh2B ZinvCecjOBljm5MpA7s657MF7L121NNiMfhkXRaD3MAmBKz+KQR1+MGAlhEDdyMdb9EO QN+4fWFroFZ2h0Ag5WLvESviQjNlchkkCJCPrQrH1Gl4WwxjTXNr185OY2CmHPcn8D/6 S5ErTJsVMbVUxW5hvS60oWPWgLa8VuDkQC8PeyPLuUweIuPGMYhZo/K15RlwmiIB1kuN 8ung== X-Gm-Message-State: APjAAAWe+QePThbP6qYNUZbfZnxdmsWf8PtPCGhq91MD8VwnblKVGc5J 7ElyIICwNquNJqFbMQyrR1UkmaP7VwKxdpKF+Xg= X-Google-Smtp-Source: APXvYqzeT2ImPCmhA5SDBsC2vMcTLvHtZR04CtTu+xIx8IFN+Fh3ek7kJlcUuXO1goro6oKLRAMs7emuMyZWK1vlLYE= X-Received: by 2002:a5d:9053:: with SMTP id v19mr1641607ioq.49.1552643133497; Fri, 15 Mar 2019 02:45:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 15 Mar 2019 09:45:22 +0000 Message-ID: To: Theodore Brown Cc: Nikita Popov , PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures From: joshdifabio@gmail.com (Josh Di Fabio) On Thu, Mar 14, 2019 at 7:42 PM Theodore Brown wrote: > > On Thu, March 14, 2019 10:41 AM Nikita Popov wrote: > > > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov 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 > > > > As a small update, I've implemented a proof of concept that uses the ($x) > > ==> $x * $multiplier syntax (or $x ==> $x * $multiplier for short) in > > https://github.com/php/php-src/pull/3945. As mentioned in the RFC, this > > requires scanahead in the lexer. > > > > This syntax is in principle still on the table, though personally I prefer > > fn($x, $y) => $x * $y over ($x, $y) ==> $x * $y. The main redeeming quality > > of ==> is that it supports the paren-less variant $x ==> $x. Taking into > > account the lexer hackery it requires (and which will also be required in > > any 3rd party tooling), this would not be my preferred choice. > > > > I agree that the nicest thing about this syntax is the ability to save > an additional 3 characters of boilerplate for the common use case of > single-parameter arrow functions. However, I'm also not a fan of adding > complex code hacks to make the syntax work. > > One alternative that doesn't seem to have had much discussion on list > is the `\($x) => $x * $y` lambda syntax. This would also allow parentheses > to be omitted for single parameters, making it just as terse as the ==> > syntax without the need for any lexer hackery. > > Here's how the examples from the RFC would look: > > ```php > function array_values_from_keys($arr, $keys) { > return array_map(\$x => $arr[$x], $keys); > } > > > $extended = \$c => $callable($factory($c), $c); > > > $this->existingSchemaPaths = array_filter($paths, \$v => in_array($v, $names)); > > > function complement(callable $f) { > return \(...$args) => !$f(...$args); > } > > > $result = Collection::from([1, 2]) > ->map(\$v => $v * 2) > ->reduce(\($tmp, $v) => $tmp + $v, 0); > ``` > > One argument against this shorter syntax is that it wouldn't be as > easy to google as `fn`. However, long term I think everyone would > still get used to it, and I'm personally willing to add an answer > to the top Stack Overflow search result for "php backslash keyword". > > The backslash syntax has precedent from Haskell, and also wouldn't > introduce any BC break (who knows how many private codebases might > already have functions named `fn`). > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > I'd certainly be on board with the fn() syntax, but the backslash syntax has definitely grown on me. To me, all of the examples in Theodore's email are very readable and I find that the backslash makes it very easy to identify arrow functions when grokking. array_filter($numbers, \$n => $n % 2); vs. array_filter($numbers, fn($n) => $n % 2); When grokking these two pieces of code, I immediately see "\$n => $n % 2" as a single unit, whereas in the latter example I instinctively (and incorrectly) interpret "fn($n)" as an expression. When parens are required, the difference is obviously reduced, but I think I still prefer the backslash syntax since the LHS doesn't grok as a function call. reduce($numbers, \($x, $y) => $x + $y); vs. reduce($numbers, fn($x, $y) => $x + $y); That said, I'd personally take either syntax gladly.