Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104714
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CALKiJKqCJys2CRFtLPzPO07vsS123z9Bw-meOad0tL7Gd8rf1g@mail.gmail.com> <CAG9XoMTTmpr47b7nE3XRUehgzAgKG9Bask7Fhu6v=b0dT7SgRQ@mail.gmail.com>
In-Reply-To: <CAG9XoMTTmpr47b7nE3XRUehgzAgKG9Bask7Fhu6v=b0dT7SgRQ@mail.gmail.com>
Date: Thu, 14 Mar 2019 14:54:32 +0000
Message-ID: <CALKiJKpFSUsZY0xM8aSR2BVwe7v0pJxZQ_y-XnHnDfVrtwcvgA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000040d5b705840f1a20"
Subject: Re: [PHP-DEV] [RFC] Arrow functions / short closures
From: rowan.collins@gmail.com (Rowan Collins)

--00000000000040d5b705840f1a20
Content-Type: text/plain; charset="UTF-8"

On Thu, 14 Mar 2019 at 14:12, Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> This makes me thinking, has this syntax been considered?
>
> ($x) => { $x * $y }
>
> Nested:
>
> ($x) => { ($y) => { $x * $y } }
>


Wouldn't this have all the same parser problems as the RFC discusses?

The problem, as I understand it, is not avoiding ambiguity, it's avoiding
lookahead. If you write:

$foo = [ ($x) => { $x } ];
$bar = [ ($x) => $x ];

The parser has already consumed " [ ($x) =>" before it can decide if each
($x) is an array key or a closure signature. It's parseable, but only using
one of the workarounds described in the RFC.

If I'm understanding the RFC correctly, the only way to avoid that is to
have closures *start* differently from other valid constructs, because then
the parser doesn't need to recurse / backtrack / etc.

Regards,
-- 
Rowan Collins
[IMSoP]

--00000000000040d5b705840f1a20--