Den søn. 28. mar. 2021 kl. 14.30 skrev Deleu <deleu...@gmail.com>:
>
> 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.
I think we have some sort of conundrum. I am not saying auto capture
is not good semantics if that is what you are implying, I more than
anyone would like consistency in the language but it is not a good
language design to have two very similar features separated by a
shorter keyword which implies totally different semantics. I don't
find this a very intuitive way nor a good developer experience. I can
understand that the connection of the `fn` keyword already having the
meaning it has, but then we can bring up the side running RFC from
Larry which proposes to make the same short syntax available for other
function declarations, how would this work then with this mindset of
`fn` meaning auto capture? Does that mean a procedural function
declared with `fn` will now inherit the scope from which it was
declared (usually the global scope)? What about methods declarations,
do they import properties into the local scope? How does traits
interact here, same as methods?
This is why I think having the `fn` being an alias of `function`
neutralizes the argument of what happens for exactly those reasonings
above, this allows arrow functions to continue being auto capture
without any keyword. And again; adding an `auto` keyword is also not
an alien thing to Closures because we already have the `static`
keyword which acts as a feature flag, something which arrow functions
already support which also is a case that can easily mess up the order
of which objects are destructed in if you make a Closure that does not
interact with `$this` from an object context without declaring it as
`static`.
While I did not agree with this in the initial RFC that implemented
arrow functions, I do see its value and agree with it due to the
narrow scope of which arrow functions have, and therefore I think it
is fine to have the exception of making arrow functions behave this
way and would have voted as such had it come to my desk today.
And again, kindly stop top posting.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
