I'd strongly prefer a syntax without the introduction of "fn" keyword -
e.g. similar to closures in other languages.
I also feel that there's a feature missing - something that was possible
with closures:
$total = 0;
$add = function ($value) use (&$total) {
$total += $value;
};
Per the RFC:
> When a variable in the expression is defined in the parent scope it will
be captured implicitly by-value
Whether you regard it as a good thing or bad thing (I'm only pointing it
out) this is inconsistent with JavaScript, where variables in the parent
scope are captured by-reference.
If we're introducing a new form and syntax for closures, why not make this
one align with something that's going to be familiar with developers?
That's just my opinion, but whether you agree with that or not - as long as
we're introducing a new form and syntax, why make it *less* capable than
ordinary PHP closures? At the very least, I feel there should be feature
parity - otherwise, code in the wild is going to continue to be a strange
mess of one form or the other, which doesn't help with language
comprehension at all, especially when both forms also work differently from
JavaScript closures, which are likely the form of closures that
web-developers are going to be most familiar with.
Don't get me wrong, I'm not saying "make it like JavaScript" - what I'm
saying is, make something that is familiar to developers *somehow*, e.g.
either provide feature parity with ordinary PHP closures and make it
familiar to PHP developers, *or* make it similar to JavaScript closures,
but don't throw yet another "original" idea on the pile.
Ultimately, I think what I'd like to see would be something along the lines
of this:
$total = 0;
$add = ($value) => {
&$total += $value;
};
That is:
- Lose the fn keyword - get the syntax down to something similar to
closures in most other languages.
- Keep it working like PHP (which you intend to do anyhow) in terms of
importing variables by-value.
- Provide feature parity with regular PHP closures by providing some means
of accessing variables by-reference.
I understand that the fn keyword is there to remove ambiguities, but I
think working around the ambiguities is possible, even if it's difficult -
there was ambiguity with < and > operators in the run-of-the-mill generics
syntax I proposed last year, and Dominic Grostate was able to work through
them and get it to parse after all. I understand it's probably difficult,
and it may not be possible to achieve something that is 100% technically
correct, but it's usually possible to achieve something that works for
almost any real-world use-case.
The last thing I would comment on is multi-statement bodies. Omitting this
is, in my opinion, a very bad decision - it will, again, lead to lack of
feature parity with regular closures, which will mean, in practice,
factoring back and forth between regular closures and fat arrow functions,
which will be frustrating. It will also encourage developers to attempt to
fold complex operations into a single expression, leading to further
frustration for the programmer, and unreadable code for collaborators,
because "damnit I'm not going back to regular closures!", right?
In my opinion, if you can't provide feature parity on these points with
regular closures, this feature will hurt more than help - it will lead to a
lot of meaningless struggles, unreadable code, and code that doesn't
refactor well, and, eventually, BC breaks when PHP 7.x finally does
introduce these missing features.
On Mon, Jan 30, 2017 at 6:55 PM, Levi Morrison <le...@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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
