Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127577
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 04 Jun 2025 11:23:39 +0200
To: Dmitry Derepko <xepozzd@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC: Single-Expression functions
In-Reply-To: <CANTuiHuOxuwB2oTvPNekdkUCJbxWHMMrXjzQfHo2Tsui6NyoXw@mail.gmail.com>
References: <CANTuiHuOxuwB2oTvPNekdkUCJbxWHMMrXjzQfHo2Tsui6NyoXw@mail.gmail.com>
Message-ID: <68682212b6cc36ebd775e2504d941079@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-05-22 11:24, schrieb Dmitry Derepko:
> I hope this message finds you well. I would like to respectfully 
> propose
> single-expression functions for PHP:
> https://wiki.php.net/rfc/single-expression-functions

Thank you for updating the RFC to match the template. I've read through 
it and have some comments:

1.

In the implementation I'm seeing that `$a = function() => 123;` will 
also become legal (“short closures with function instead of fn”). This 
is not mentioned in the RFC text. It also raises the question how that 
variant will interact with variable capturing.

2.

An AST printing test in the implementation would be useful to have. You 
can do that with `assert(false && new class { });` (using an anonymous 
class).

3.

I believe the reasoning given is not a fair comparison. The RFC says 
that `getName() "Name"` would be the relevant information, which I can 
agree with. But this is not what the proposed syntax looks like. A fair 
comparison would be:

     function getName() { return "Name"; }
     function getName() =>       "Name";

And when compared like this, it becomes clear that you are trading `{}` 
for `=>` and effectively only save the `return`, which to me provides 
little incremental value. Especially when comparing the signatures from 
the Calculator example:

     public function multiply(int $a, int $b): int       => $a * $b;
     public function multiply(int $a, int $b): int { return $a * $b; }

I also don't like how the actual implementation is pushed to the right 
of the line. This makes it harder for me to scan for it. The linebreaks 
that the RFC states “create cognitive overhead” guide the eye for me. So 
perhaps we should also compare:

     public function multiply(int $a, int $b): int
         => $a * $b;
     public function multiply(int $a, int $b): int {
         return $a * $b;
     }

So basically the only thing we gain is the removal of a keyword in some 
situations. When trying to extend the logic in a function to more than 
one expression (which is not unlikely for methods), I would be forced to 
make multiple “boilerplate” changes instead of just adding my logic, 
effectively undoing any benefit the syntax might've provided.

Thus I'm very skeptical that the RFC provides sufficient value to 
justify the impact on the ecosystem (e.g. IDEs, static analyzers, 
documentation, confusion regarding another closure syntax, …).

Best regards
Tim Düsterhus