Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98137
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAFMT4Nq_vbCRmMZ2OSDN7_VqGG6UR6PTNevz3DWLF9K8MODMYg@mail.gmail.com>
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <CAFMT4Nq_vbCRmMZ2OSDN7_VqGG6UR6PTNevz3DWLF9K8MODMYg@mail.gmail.com>
Date: Fri, 3 Feb 2017 10:53:18 -0700
Message-ID: <CAFMT4NoxVT3JGLmT-8Vj5R4c-h-m9xK20nG3vQHyBKx3aNX3Og@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC][Discuss] Arrow Functions
From: levim@php.net (Levi Morrison)

On Fri, Feb 3, 2017 at 10:48 AM, Levi Morrison <levim@php.net> wrote:
> On Mon, Jan 30, 2017 at 10:55 AM, Levi Morrison <levim@php.net> wrote:
>> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
>> RFC is moving into the public discussion phase. We have been
>> collaborating on this RFC for many months now and finally have a
>> proposal we are happy to discuss in the open.
>>
>> Here is an example of an existing closure:
>>
>>     function ($x) use ($arr) {
>>         return $arr[$x];
>>     }
>>
>> This RFC proposes syntax and semantics to simplify this common usage to:
>>
>>     fn($x) => $arr[$x]
>>
>> More details are in the RFC. The [implementation][2] currently has no
>> known issues and is ready for you to download, build and test, which
>> we encourage you to do.
>>
>> We look forward to a productive discussion period and are happy to
>> answer questions.
>>
>> For historical purposes, the revision of this RFC is currently at
>> [1485798604][3].
>>
>>   [1]: https://wiki.php.net/rfc/arrow_functions
>>   [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions
>>   [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604
>
> Thanks to everyone who has participated in the discussion thus far.
> Primarily the feedback has been directed at the `fn` keyword. Let me
> provide two benefits and drawbacks of using `fn` as a keyword:
>
>   1. `fn` is searchable in search engines and in our manual
>   2. Is more intuitive than just syntax
>
> However, `fn` does have downsides:
>
>   1. Can break existing code
>   2. We already have a similar keyword `function`
>
> To that end, I'd like to gauge interest in a pure syntax based
> alternative that is similar to Rust and Ruby.
> Instead of:
>
>     fn(params) => expr
>
> What about:
>
>     |params| => expr
>
> This trades the advantages of the keyword for the advantages of pure
> syntax, and happens to be two characters shorter. To be explicit:
>
>     1. Preserves 100% backwards compatibility
>     2. Avoids having two keywords that both mean "function"
>     3. Is not easily searchable in engines or in the manual
>     4. Is a tad bit shorter
>
> What do you think, Internals?

One more thing: I'd like to re-emphasize that the syntax that
JavaScript uses and the one that HHVM/Hack uses are ambiguous in the
current class of our grammar. The following will not work unless we
move to a more powerful grammar and parser class:

    (params) => expr
    (params) ==> expr

This is why an un-ambiguous prefix is necessary: the prefix breaks the
ambiguities. The syntax I have suggested in the RFC and the one I
suggested just now are not ambiguous because distinct prefixes:

    fn(params) => expr
    |params| => expr

I look forward to more discussion!