Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.150 as permitted sender)
Message-ID: <BLU436-SMTP4506E841E18C53E37A3CF4E24A0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_101A18C7-6528-4A57-AB90-72A5441E5C6E"
MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 31 Jan 2017 12:14:47 +0100
In-Reply-To: <642a72cd-e322-0b22-452f-dfbd521aee02@php.net>
CC: PHP internals <internals@lists.php.net>
To: Michael Wallner <mike@php.net>,
 Andrea Faulds <ajf@ajf.me>,
 php-lists@koalephant.com
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>
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_101A18C7-6528-4A57-AB90-72A5441E5C6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hey,

> Am 31.01.2017 um 11:23 schrieb Michael Wallner <mike@php.net>:
>=20
> On 31/01/17 05:53, Stephen Reay wrote:
>> Hi Andrea, All,
>>=20
>>> On 31 Jan 2017, at 08:12, Andrea Faulds <ajf@ajf.me> wrote:
>>>=20
>>> Is it necessary to introduce a new keyword, fn?
>>>=20
>>> I think you'd get a similar benefit from:
>>>=20
>>>   function($x) =3D> $arr[$x]
>>>=20
>>> Likewise, is it necessary to restrict auto-capture to the =3D>
>>> syntax? Couldn't we allow the following?
>>>=20
>>>   function ($x) {
>>>       return $arr[$x];
>>>   }
>>>=20
>>=20
>> I agree that the `fn` keyword isn=E2=80=99t really necessary. I=E2=80=99=
ve never
>> quite understood how arrow functions with implied returns etc are
>> supposed to make for *more* readable code, but if they=E2=80=99re =
going to be
>> part of the language please at least keep some consistency with
>> regular closures.
>=20
> Yes, I also think that keeping the function keyword would be better.
>=20
>>=20
>> 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 =
inherit the
>> variables you explicitly `use()` in closures.
>=20
> 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 =
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) =3D> $x + 1)

to

array_map(function($x) =3D> $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=

--Apple-Mail=_101A18C7-6528-4A57-AB90-72A5441E5C6E--