Hi, Internals!
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
I've had extensive experience working with Kotlin, which offers a modern
approach to Java development and enables cleaner, more intuitive code.
Through this experience, I've encountered various concise syntax features,
and I believe one of them—single-expression functions—could be a valuable
addition to PHP.
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.
I believe this proposal aligns well with PHP's current modernization
efforts and the ongoing initiative to simplify various language constructs.
PHP has been consistently improving developer experience through features
like property promotion, arrow functions, the nullsafe operator,
getters/setters, and other syntax enhancements. This single-expression
function syntax would be a natural continuation of this trend, further
streamlining the developer workflow and making PHP more pleasant to write.
The primary motivation is to help streamline "data classes" by eliminating
the need for "{", "return", and "}", which can sometimes account for up to
30% of the code in such classes. This improvement would be particularly
timely as it directly enhances developer experience—a key focus of PHP's
recent evolution.
I would greatly appreciate your thoughts and feedback on this proposal, and
I'm looking forward to engaging in constructive discussion with the
community.
Thank you for your time and consideration.
Dmitriy Derepko
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 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 hookspublic 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
Like Anton, I believe the arguments for using => and not = are strong, as detailed in the original RFC. Other than that, I am unsurprisingly in favor of short-function syntax.
If memory serves, the main argument against last time was "it doesn't actually do anything." It's purely sugar. Which is true, but IMO also not a fully compelling argument. Constructor promotion is purely sugar, but it absolutely makes life better. The short-hooks syntax is purely sugar, but makes life better. The question is whether the QoL improvement of the sugar justifies the engine complexity + conceptual complexity (for readers) that every feature comes with.
In this case, the engine complexity is not zero, but pretty close to it. The conceptual complexity is also low, especially if using =>. It is already established to mean "evaluates to", which is exactly what is described here. So the overall cost of this change would be quite low.
While the QoL benefit is not as large as it was for constructor promotion (which was huge), I do believe it is large enough to justify the fairly low cost. Especially as we integrate more and more expression-oriented features over time (pipes, null-safe methods, match(), throwable expressions, etc), which increases the surface area where the benefits will be felt.
--Larry Garfield