2021-03-25 16:02 GMT+01:00, Mike Schinkel <m...@newclarity.net>:
>
>
>> 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.I don't understand why this is a target in the first place. Shorter does not mean more readable, and readable is more important than writable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
