Re: [RFC] Auto-capture multi-line closures and shortfunctions take 2

> On Mar 25, 2021, at 10:41 AM, Rowan Tommins <rowan.collins@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();