> prettier to read Are they though? Because if it implicitly captures anything in scope, there are more lines to read to figure out what's actually captured.
2021-03-25 13:31 GMT+01:00, Nuno Maduro <enunomad...@gmail.com>: > Hi, > > Thank you for the feedback on this thread so far. Programmers are > opinionated, therefore you will find developers that see themselves using > this RFC and others who don't. Just like "Fibers", "Type-hints", or any > other feature in the language really. > > 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. [1] > > 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. And, the "=>" sigil always means > "evaluates to the expression on the right" in all circumstances - one-line > short closures, named functions, arrays, and match() already follow these > patterns. [3] > > On the other hand "use (*)" has no usages / or current meaning in the > language. > > Thanks, > Nuno. > > [1] Pretty much "Brent Roose" have said here: > https://externals.io/email/112010/source > [2] https://wiki.php.net/rfc/short-functions > [3] Check "Auto-capture multi-statement closures" - > https://wiki.php.net/rfc/auto-capture-closure. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
