Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104713
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CALKiJKqCJys2CRFtLPzPO07vsS123z9Bw-meOad0tL7Gd8rf1g@mail.gmail.com>
In-Reply-To: <CALKiJKqCJys2CRFtLPzPO07vsS123z9Bw-meOad0tL7Gd8rf1g@mail.gmail.com>
Date: Thu, 14 Mar 2019 15:12:03 +0100
Message-ID: <CAG9XoMTTmpr47b7nE3XRUehgzAgKG9Bask7Fhu6v=b0dT7SgRQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005b25d505840e826a"
Subject: Re: [PHP-DEV] [RFC] Arrow functions / short closures
From: benjamin.morel@gmail.com (Benjamin Morel)

--0000000000005b25d505840e826a
Content-Type: text/plain; charset="UTF-8"

This makes me thinking, has this syntax been considered?

($x) => { $x * $y }

Nested:

($x) => { ($y) => { $x * $y } }

AFAICS, we don't need the brackets around the whole expression, as this
should be parsable without any ambiguity; and the syntax would be closer to
that of JavaScript.


On Thu, 14 Mar 2019 at 14:44, Rowan Collins <rowan.collins@gmail.com> wrote:

> On 13 March 2019 15:56:40 GMT+00:00, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >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
>
> Hi Nikita,
>
> Thanks for reviving this. I think the RFC does a great job of
> justifying both the syntax and the behaviour, and focusing on the most
> used features without ruling out further additions in future. In
> particular, I think whether and how we support auto-capture in full
> function bodies has its own pros and cons to debate, separate from
> auto-capture as a convenience in short "lambda" expressions.
>
> I was initially quite drawn to a block-style syntax. As someone not
> particularly familiar with functional programming (which I suspect
> puts me in the majority of PHP users), I actually find it easier to
> spot this as "a closure returning a closure":
>
> { ($x) => { ($y) => $x * $y } }
>
> rather than having to work out the associativity of chained operators:
>
> fn($x) => fn($y) => $x * $y
>
> However, I imagine the only people who will heavily use such a
> construct will be those who *are* familiar with functional programming
> in other languages, and will find the simpler syntax more familiar and
> convenient.
>
> It would also be ugly to add full block bodies in a similar style like
> { ($x) => { ... } }, and while I'm not convinced we need that, we
> probably don't want to rule it out completely.
>
> As such, I support the RFC in its current form.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0000000000005b25d505840e826a--