On Fri, Feb 3, 2017 at 10:48 AM, Levi Morrison <[email protected]> wrote:
> On Mon, Jan 30, 2017 at 10:55 AM, Levi Morrison <[email protected]> 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!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php