> On Mar 25, 2021, at 10:41 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> 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.
And yet adding " use (*)" makes the syntax longer, which goes against one of
the goals many people have for it: to be shorter.
> * There is no obvious way to expand it to support any by-reference capture,
> which is something people have previously expressed a desire for.
Can you please clarify why "function(...) use(...) {...}" can't be their
solution when someone needs by-reference capture?
-Mike
P.S. BTW, if we *had* to enable by-ref for "fn(...)" then I would argue it
should be a terse syntax, e.g.:
$callable = fn()(&$foo) => $foo= bar();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
