Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98136
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: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
Date: Fri, 3 Feb 2017 10:48:45 -0700
Message-ID: <CAFMT4Nq_vbCRmMZ2OSDN7_VqGG6UR6PTNevz3DWLF9K8MODMYg@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 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?