>
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
> lookahead.
You're right, I was only thinking about resolving the ambiguity with array
keys. It's too bad if the parser implementation considerations take
precedence over the purity of the language, but I can understand the
maintenance nightmare that people are trying to avoid here.
Something else that crosses my mind, is: what prevents us from using the
same syntax as ES6:
($x) => $x * $y
But to prevent any ambiguity, forbid array keys from being enclosed with
parenthese? For example, the following would be considered an array
containing a closure:
[ ($foo) => "bar" ]
And the following would just become a syntax error:
[ ("foo") => "bar" ]
Would that solve the parser problem? BC-wise, I don't think this would be
much of a problem: I have yet to see array keys enclosed with parentheses
in PHP codebases.
On Thu, 14 Mar 2019 at 15:54, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On Thu, 14 Mar 2019 at 14:12, Benjamin Morel <benjamin.mo...@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]
>
