On Thu, May 22, 2025, at 8:53 PM, Anton Smirnov wrote:
> Hi Dmitriy
>
> On 22/05/2025 12:24, Dmitry Derepko wrote:
> > 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
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
