Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98071
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.219 cause and error)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP4506E841E18C53E37A3CF4E24A0@phx.gbl>
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <E6.ED.51557.B64EF885@pb1.pair.com> <3F428CA4-8211-44E6-9B60-62ADB47934B3@koalephant.com>
 <642a72cd-e322-0b22-452f-dfbd521aee02@php.net> <BLU436-SMTP4506E841E18C53E37A3CF4E24A0@phx.gbl>
Date: Tue, 31 Jan 2017 12:53:48 +0100
Message-ID: <CANUQDChSokTQ1e__6baj0ch6LphY_uS7FvqEs5Rd9zKW+RZ0cQ@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Michael Wallner <mike@php.net>, Andrea Faulds <ajf@ajf.me>, Stephen Reay <php-lists@koalephant.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c065d98cdccd905476295d8
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: me@kelunik.com (Niklas Keller)

--94eb2c065d98cdccd905476295d8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2017-01-31 12:14 GMT+01:00 Bob Weinand <bobwei9@hotmail.com>:

> Hey,
>
> > Am 31.01.2017 um 11:23 schrieb Michael Wallner <mike@php.net>:
> >
> > On 31/01/17 05:53, Stephen Reay wrote:
> >> Hi Andrea, All,
> >>
> >>> On 31 Jan 2017, at 08:12, Andrea Faulds <ajf@ajf.me> wrote:
> >>>
> >>> Is it necessary to introduce a new keyword, fn?
> >>>
> >>> I think you'd get a similar benefit from:
> >>>
> >>>   function($x) =3D> $arr[$x]
> >>>
> >>> Likewise, is it necessary to restrict auto-capture to the =3D>
> >>> syntax? Couldn't we allow the following?
> >>>
> >>>   function ($x) {
> >>>       return $arr[$x];
> >>>   }
> >>>
> >>
> >> I agree that the `fn` keyword isn=E2=80=99t really necessary. I=E2=80=
=99ve never
> >> quite understood how arrow functions with implied returns etc are
> >> supposed to make for *more* readable code, but if they=E2=80=99re goin=
g to be
> >> part of the language please at least keep some consistency with
> >> regular closures.
> >
> > Yes, I also think that keeping the function keyword would be better.
> >
> >>
> >> 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 =E2=80=98fun=E2=80=99 I kind of like that with PHP you only in=
herit 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 =E2=80=98fun=E2=80=99 I kind of like that with PHP you only in=
herit 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) =3D> $x + 1)
>
> to
>
> array_map(function($x) =3D> $x + 1)
>

"function" is actually easier to recognize than "fn" for me. Humans read
things by the first and last letter + contained letters, they don't read
each letter separately, so a little bit longer keyword doesn't hurt
readability, it might be even improved, because "function" is a keyword
people are used to. And it comes with the benefit of no BC break, because
"function" is already a keyword.

Also updating

array_map(function ($x) =3D> 2 * $x, [...]);

to

array_map(function ($x) use (...) { ... }, [...]);

is a little bit easier then, just in case you need an additional statement
there.


> The syntactical construction is already pretty clearly showing what's
> going on. The "function" keyword itself is already larger than the whole
> body.


Now we're counting chars again instead of keeping the focus on actual
readability?


> It distracts while reading the actual code.
>

I disagree here, as mentioned above.


> 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 think I prefer "function" instead of "fn", but I can also live with "fn".

Regards, Niklas

--94eb2c065d98cdccd905476295d8--