Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113773
To: internals@lists.php.net
References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.com>
 <CAF+90c9PRmK1FM_uUO3qMhhvMybY4z_aZkmMO53TVfuy--U32g@mail.gmail.com>
 <CAPKYkKxTgHnzXKwkHi4qgJewY86vWFehrhN39fyrrK5KWNVvig@mail.gmail.com>
 <4DC3B66E-A91A-4AA9-8872-8EE9DE92C2D4@cschneid.com>
 <8c72c162-83c0-7c7f-2fa7-4fbe3fb30a4a@gmail.com>
 <605bae82.1c69fb81.f49f7.d11eSMTPIN_ADDED_MISSING@mx.google.com>
 <919e30e7-3e5e-d955-7bb4-1e1b5825cdd1@gmail.com>
 <635DD146-FC6F-4991-8D2C-5A6B492722D5@newclarity.net>
 <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com>
 <CALZWoqXZF9wegVGwGMjjVEV89zTjb-TYS87MqP36fSk-qJqD4g@mail.gmail.com>
Message-ID: <daffe9ec-3163-25cc-bb52-587fbd2230bb@gmail.com>
Date: Thu, 25 Mar 2021 14:41:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CALZWoqXZF9wegVGwGMjjVEV89zTjb-TYS87MqP36fSk-qJqD4g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: rowan.collins@gmail.com (Rowan Tommins)

On 25/03/2021 12:31, Nuno Maduro wrote:

> The reason why we believe the vast majority of PHP Developers are going to
> appreciate this RFC is because multi-line short closures (aka
> Auto-capturing multi-statement closures) *are more simple, shorter to
> write, and prettier to read *— and the community love these changes as
> proven on "property promotions", "one-line short closures", etc.


My main point was that the RFC needs to spell out this argument, rather 
than taking it for granted that everyone agrees on "those situations 
where that is warranted".

Most of the current text should be summarised in a "syntax choices" 
section somewhere near the end. I would like to see much more space 
devoted to:

* Why we need this feature. What has changed since it was left out of 
the arrow functions RFC? What problems is it addressing? Why do you 
think it is the best approach to those problems?
* The exact semantics proposed: How will the variables to be captured be 
determined? Will it distinguish variables which are written before 
they're read, and if so how is that defined? Can auto-capturing closures 
be nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from 
the outermost scope? And so on...


> Besides, one advantage of this RFC is that it is consistent with the
> current syntax of the language and with the short-functions RFC[2]. For
> example, by proposing that "fn" keyword indicates a function will
> auto-capture variables, by value.


While it's a cute rationalisation, there's no intuitive reason why "fn" 
should have that meaning; we could pick any aspect of the current arrow 
function syntax and say "the 'fn' keyword means that".



> On the other hand "use (*)" has no usages / or current meaning in the
> language.


This is a straw man argument. I could equally say that "fn() { } has no 
usages or current meaning in the language" - of course it doesn't, we 
haven't added it yet!

The "function use() {}" part of "function use(*) {}" has a 
well-established meaning, and "*" to mean "everything" is a notation 
developers are likely to be very familiar with.

The two disadvantages I see with using "fn" as proposed are:

* Because it's shorter, people will decide it's the "better" version, 
when they don't actually need any variable capture. An explicit syntax 
like "use(*)" instead makes this a deliberate choice.
* There is no obvious way to expand it to support any by-reference 
capture, which is something people have previously expressed a desire for.


Regards,

-- 
Rowan Tommins
[IMSoP]