RFC: Single-Expression functions

Hi Dmitriy

I'm aware that Larry Garfield previously proposed a similar feature
several years ago, though it unfortunately didn't pass the voting stage.
I would like to respectfully suggest that using "=" instead of "=>" to
separate declaration and implementation might be a better approach.
That looks like the weakest part of the proposition because we already
have two places where inline bodies are used: the mentioned arrow
functions and property hooks

public string $foo { get => 'dynamic value'; }

No sense in introducing a new syntax for basically just another case of
inline function body.

// oneline
function handle(string $input): string = func1($input) |> func2(...)
|> func3(...) |> func4(...);

That looks like a callable assignment like you know

$f = fn ($bar) => $this->bar + $bar;

class Foo {
private $bar;

   public function bar() = $f;

}

that may confuse users, another argument for =>

--
Anton

Hi Dmitry

Thanks for your interest in improving PHP.

https://wiki.php.net/rfc/single-expression-functions

In the "Single-Expression functions in other languages" section, at least the Rust and Swift examples are wrong, as such a syntax does not exist for either of them. In case you got this info from an LLM, you should always fact-check whatever an AI tells you.

Ilija

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:

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.

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).

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