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

The fact that short closure is inconsistent with the rest of PHP is a done deal since the voting passed prior to 7.4 release. Unless there's a follow-up to deprecate the 7.4 short closure auto capture without auto keyword and make it look like PHP can't make up it's mind, I feel that your perspective doesn't match the proposed RFC. The RFC is extending short closure to support multiple statements and defining good semantics on how developers will interpret fn, => and {} throughout the language. On Sun, Mar 28, 2021, 12:21 Kalle Sommer Nielsen <kalle@php.net> wrote: > Den søn. 28. mar. 2021 kl. 13.02 skrev Deleu <deleugyn@gmail.com>: > > > > This would lead to inconsistent behavior in the language when short > closures auto capture without the auto keyword while multi statements > closure doesn't. > > One of the best features of these RFC are their cognitive definition > that is clear, concise, consistent and simple. > > (First off, please read our mailing lists rules[1] and do not top post) > > If we go by the inconsistent behavior then by that definition short > arrow functions are inconsistent with the rest of PHP as there is no > auto capture elsewhere. > > This is not short arrow functions being expanded to support multi > lines, but rather the other way around, with multi line closures being > able to support auto capture which is identified by the fn > keyword > and because of that, I would much rather have a fn be an alias > of > function and then having the ability to put a keyword to > declare > that you wish to use auto capture (which is consistent with the > exisiting design of PHP where you have to declare globals with the > global keyword or explicit imports to closures with the > use > statement (which used to be done by the lexical keyword > similarily > to the global keyword in early PHP 5.3.0 development) -- if you > are > interested in this philosophy you can try lookup videos from some of > Rasmus' presentations where he explains his dislike with globals > coming from C). To back this up further, we also have the Ð' > LHU{f?j}V5ê2static > keyword which acts as a feature flag so it is not unnatural, the > naming of the keyword auto sure, but that is another > discussion. > > [1] > > https://git.php.net/?p=php-src.git;a=blob_plain;f=docs/mailinglist-rules.md;hb=HEAD > > regards, > > Kalle Sommer Nielsen > kalle@php.net >