> > 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? >
I think I remember the 1st version of Larry's RFC proposing `public fn classMethod(): bool => $this->myAttr;` as a class method which seems to match what you're trying to say here, but that has been withdrawn and the RFC no longer proposes the fn keyword for class methods or function declarations, which is discussed under *Background* of RFC https://wiki.php.net/rfc/auto-capture-closure. Larry and Nuno may correct me if I'm wrong but as far as I understood, that change happened to address exactly the points you're describing here: what does `public fn classMethod(): bool` would capture? There's actually little to no reason to do it. Larry's RFC still proposes a great improvement for getters/setters/short methods and Nuno's RFC allows us to write code that is naturally expected to work, such as `fn () => {...}`. As for making `fn` an alias of `function` I believe that is already broken because of 7.4 arrow functions. As you describe, that would be "an exception" to PHP syntax, but more pressing it means that we would be wasting the potential of 2 separate keywords having different goals. I think it was Nikita that once said that we have a very limited budget on what we can do/offer through programming syntax and throwing `fn` out would be such a waste of that limited budget. -- Marco Aurélio Deleu
