Re: [RFC][Discuss] Arrow Functions
| From: | Levi Morrison | Date: | Fri, 03 Feb 2017 17:48:45 +0000 |
| Subject: | Re: [RFC][Discuss] Arrow Functions | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98136@lists.php.net to get a copy of this message | ||
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?