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

Den søn. 28. mar. 2021 kl. 14.30 skrev Deleu <deleugyn@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 kalle@php.net