Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.192.180 cause and error)
MIME-Version: 1.0
In-Reply-To: <2f9e73c9-444a-11d0-459a-e261ea8a7080@telia.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <DM3PR18MB07641E547AD2FA1DFA5BEF65DEF60@DM3PR18MB0764.namprd18.prod.outlook.com>
 <6357d97c-3f2e-4cf8-cb1f-cb7f7ccccf7c@telia.com> <CADqTB_hNob7ZiGX66gJEpCymrZJqqsZ1uAGnYg6v6sbrwx1-KQ@mail.gmail.com>
 <7eaef49b-bf60-9aa1-e812-8430164e3178@garfieldtech.com> <f5992058-aecd-8bc4-08f8-2bfe722cd41e@fleshgrinder.com>
 <3F920987-38CB-42DD-888D-824430C36F14@gmail.com> <2f9e73c9-444a-11d0-459a-e261ea8a7080@telia.com>
Date: Mon, 5 Jun 2017 20:36:13 +0200
Message-ID: <CADqTB_hWrhBBQetfp=-LFR=OYALHwhs=mYd3vPQOYGGng26UsA@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c1b592e1f682e05513ac739"
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: rasmus@mindplay.dk (Rasmus Schultz)

--94eb2c1b592e1f682e05513ac739
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ugh, you're right, that's totally unreadable... the =3D> is far too ambiguo=
us
with array syntax, I agree.

How about just a thin arrow?

    (params) -> expr

If the parens around params were required, it's not ambiguous with the
trailing -- operator, is it?

    $foo->bar(($baz) -> $baz + 1);

Consistent use of parens around the params might make closures a bit easier
to spot in the wild?


On Mon, Jun 5, 2017 at 8:11 PM, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.c=
om>
wrote:

>
>
> Den 2017-06-05 kl. 19:55, skrev Rowan Collins:
>
>> On 5 June 2017 18:17:06 BST, Fleshgrinder <php@fleshgrinder.com> wrote:
>>
>>> Could someone explain me again what the problem with the simple
>>> fat-arrow and normal parenthesis is? Cannot find it anymore (too many
>>> messages in too many thread I guess). I would guess that it has to do
>>> with the arbitrary look-ahead that is required to check for the fat
>>> arrow before the lexer knows that this is a short closure and not some
>>> parenthesis that simply groups something.
>>>
>> I think it's not just a case of implementation problems, it's actually
>> ambiguous with current syntax:
>>
>> $foo =3D array( ($x) =3D> 42 );
>>
>> Sure, those inner brackets are redundant, so it's not likely to break
>> much actual code, but it's kind of weird to have this one case magically
>> turn into a closure, when anything else you put in those brackets would
>> just be used as the array key:
>>
>> $foo =3D array( f($x) =3D> 42 );
>> $foo =3D array( ($x+1) =3D> 42 );
>> $foo =3D array( (42) =3D> $x );
>> $foo =3D array( (X) =3D> 42 );
>> $foo =3D array( ($x) =3D> 42 );
>> $foo =3D array( ("$x") =3D> 42 );
>>
>> Even if we could teach the parser to understand it, I'd personally be
>> against it for the difficulty of *humans* parsing it. I find shorthand
>> closures hard enough to read anyway, especially when people suggest thin=
gs
>> like ($x) =3D> ($y) =3D> $x * $y * $z;
>>
>> Regards,
>>
>> +1, think you nailed it here :) One of the reasons I prefer the =3D=3D>
> syntax.
>
> r//Bj=C3=B6rn
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c1b592e1f682e05513ac739--