On Thu, Mar 25, 2021, at 12:12 AM, Peter Stalman wrote:
> On Wed, Mar 24, 2021 at 5:40 PM Larry Garfield <larry@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