On Thu, Mar 25, 2021, at 12:12 AM, Peter Stalman wrote: > On Wed, Mar 24, 2021 at 5:40 PM Larry Garfield <la...@garfieldtech.com> > wrote: > > > In response to the feedback that the savings in typing volume is small, > > that's true but also not the main point. The main point is to allow and > > encourage functions to be written an in "expression style", that is, as > > actual functions and not procedures. As the RFC notes, such use cases are > > increasing, and is likely to increase in PHP, and that's overall a good > > thing for the language. It fits well with a number of recent RFCs both > > passed and proposed, and makes writing functional-style code much more > > natural. > > > > Hi Larry, > > I too am wondering about the space saving aspect; as Levi showed it's quite > easy to currently write functions on one line, which really only cost 7 > more characters. Overall though, I am not a fan of the code getting wider, > and the return statements not lining up as I scroll down the code.
In practice, I've found myself writing arrow functions on 2 lines a lot, like this: $f = fn($a, $b): int => $a * $b; I find that very readable, balances height vs width well, and it's a style very popular in functional languages. I expect a lot of short-function uses to do the same, which is a good place to end up. > As for the "expression style" argument, it's a valid one. However, I'm > confused why you submitted this RFC hand-in-hand with the multi-statement > auto-capture closures. Doesn't that contradict the single statement > "expression style" argument? The short-function RFC was originally written early last fall. I put it on hold because there was also on again/off again discussion of auto-capture closures and I was warned to avoid conflicting on the syntax. I only recently got around to connecting with Nuno, who had a PR sitting around for that he'd been ignoring for a while, too. :-) They're separate proposals with their own benefits. They were (re)-presented together mainly to demonstrate that yes, we did think through the syntax to ensure that they fit well together and didn't create confusion around what certain syntax combinations mean. > Overall, I'm not really that much against it, but my only worry is that > while it is slightly less verbose it might create more cluttered code. Try a lot of 2-line functions as above. I think you'll find it's actually quite nice in practice, which is what I'm going for. > > Thanks, > Peter > > P.S. I also don't like PSR-12. Allman braces and tabs for life. Same-line braces FTW, but don't talk to me about tabs. :-P --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
