I guess that should avoid the usage of fn() or function() before arguments
(or then make it optional, but I don't like to give much options).
Some possibilites:
array_map(($x) return $x + 1); // or
array_map(($x) = $x + 1); // or
array_map(($x) => $x + 1); // or
array_map(($x) { $x + 1 });
Then:
array_map(($x) use ($y) { $x + $y });
array_map(($x) { $x + $y });
// maybe use($y) is needless here
array_map(($x) { $x + $this->y });
Or if arguments could be omitted:
array_map({ $0 + 1 });
2017-01-31 16:16 GMT-02:00 Michael Morris <tendo...@gmail.com>:
> On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield <la...@garfieldtech.com>
> wrote:
>
> > 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
> >
> >
> >
>
> For what it's worth I'd rather look at
>
> array_map( $x ==> $x + 1);
>
> than
>
> array_map( fn($x) => $x + 1 )
>
> Not to mention the former isn't a bc break.
>
--
David Rodrigues
