On 01/31/2017 05:14 AM, Bob Weinand wrote:
In the case that regular closures got auto-capture, would a
`use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
disable auto-capture), and would it have any impact (positive or
negative) on performance/memory usage? After several years of JS
closure ‘fun’ I kind of like that with PHP you only inherit the
variables you explicitly `use()` in closures.
Wouldn't there be just too many existing closures, which do not use
`use` but (maybe) expect a clean scope?
The RFC is exclusively proposing single-expression short Closures.
We do NOT want multi-statement short Closures; it is a *feature* that generic Closures
need an "use ($foo, $bar)".
This vastly improves readability and debuggability - it basically tells you
whether the variables inside the code are imported or not. As Stephen Reay
notes:
After several years of JS
closure ‘fun’ I kind of like that with PHP you only inherit the
variables you explicitly `use()` in closures.
So, auto-import for generic Closures definitely isn't an option.
Just on short, single-line Closures there is no benefit to "use ()", as EVERY
variable used in the short Closure is supposed to be an imported variable. There is no
point in forcing the user to distinguish between imported and local variable here.
Also, using "fn" in favor of "function" has the advantage of less clutter in
one line. Compare
array_map(fn($x) => $x + 1)
to
array_map(function($x) => $x + 1)
The syntactical construction is already pretty clearly showing what's going on. The
"function" keyword itself is already larger than the whole body. It distracts
while reading the actual code.
Additionally, using "fn" is optically highlighting the fact that it's a
short-Closure with auto-import and not a normal Closure with explicit import.
Thanks,
Bob
I must agree with Bob and the other authors. The entire point of this
RFC is to reduce the amount of typing, and therefore reading, that goes
into using simple closures as first-class values. Using longer keywords
instead of shorter ones is counter to that aim. It sounds like the
earlier proposal of keyword-less closures isn't technically feasible or
it would make sense to argue for that.
My question is why there's no mention of HHVM short closures, or the
previous RFC to take that approach. See:
https://docs.hhvm.com/hack/lambdas/introduction
If there's a good reason to not use that syntax, OK, but that should be
stated explicitly in the RFC with links to both HHVM and to the previous
short-closure RFC.
I also echo the previous call to clarify with examples how types would
be used, syntactically.
Since there is no "return" keyword used, that implies that no "yield"
keyword can be used, either. That is, arrow-function generators are not
supported. Is that correct? (In context they may not make sense to
have, but that should be clarified explicitly in the RFC.)
Overall I am +1 on this RFC.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
