Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104719
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CALKiJKqCJys2CRFtLPzPO07vsS123z9Bw-meOad0tL7Gd8rf1g@mail.gmail.com>
 <CAG9XoMTTmpr47b7nE3XRUehgzAgKG9Bask7Fhu6v=b0dT7SgRQ@mail.gmail.com>
 <CALKiJKpFSUsZY0xM8aSR2BVwe7v0pJxZQ_y-XnHnDfVrtwcvgA@mail.gmail.com> <CAG9XoMT+r7GxMeVO6zh9Vr2JwMbqdE2DiSLLoUxuH0pavah4fA@mail.gmail.com>
In-Reply-To: <CAG9XoMT+r7GxMeVO6zh9Vr2JwMbqdE2DiSLLoUxuH0pavah4fA@mail.gmail.com>
Date: Thu, 14 Mar 2019 15:49:07 +0000
Message-ID: <CALKiJKr1b8aaCpzVquLoqiD-gJKna5XzN7dTnzcp_RRY9t5H_Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000814fbb05840fdd46"
Subject: Re: [PHP-DEV] [RFC] Arrow functions / short closures
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000814fbb05840fdd46
Content-Type: text/plain; charset="UTF-8"

On Thu, 14 Mar 2019 at 15:10, Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> 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
>


I don't agree that this has anything to do with "purity". If JS didn't have
=> syntax, why would "fn is a shorter keyword than function" not be a good
enough reason to go with this syntax? I think it's equally valid to say
that it would be a shame for one syntax shortcut to take precedence over
the consistency and maintainability of everything else in the language. Is
it really that important to save two key strokes per closure?



> 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.
>

A quick regex search in a code base I had to hand found a few instances of
casts, like [(string)$foo => $bar], but indeed no instances of bracketed
variables. However, it would feel rather bizarre to be able to write this:

[ $x+1 => $foo ]

But not this:

[ ($x+1) => $foo ]

Which I think would have to be the implication for this to make the parsing
any easier.


On Thu, 14 Mar 2019 at 15:38, David Rodrigues <david.proweb@gmail.com>
wrote:
> maybe using [] instead of ()? For instance: "[$x] => $x + 1". PHP don't
supports and array as key, so maybe it will not causes any conflict.

Again, I think this solves the ambiguity but not the parsing, although I
could be wrong. Consider parsing these three expressions:

[ [ $foo ] ] # Nested arrays
[ [ $foo => $bar ] ] # Nested arrays with an explicit key
[ [ $foo ] => $bar ] # An array containing a closure


Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000814fbb05840fdd46--