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

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

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.

Sure I did. Seems like I was confused by specifying a variable type along
with the assigned value:

Documentation
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions/#Using-Function-Types
docs.swift.org
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions/#Using-Function-Types
[image: favicon.ico]
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions/#Using-Function-Types
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions/#Using-Function-Types
var mathFunction: (Int, Int) -> Int = addTwoInts

I’ve double checked examples and removed Swift and Rust. Thanks for that.

Best regards,
Dmitrii Derepko.
@xepozz

Hi Tim,

Great questions, I’ll try to answer them all.
Sorry for the late answer, looked like there are no interest in the RFC and I almost forgot about it.

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.

Nope. Anonymous functions won’t become available. Use arrow functions with auto-capturing instead.

RFC propose classic function and class methods become available be one-liners

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

Sure, when RFC successfully pass Voting stage, alright?

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; }

Cool point. I’ve updated examples.

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;
}

I don’t think it’s correct comparison. Why the linebreak should be there?
If it is set by an editor, it’s not programmer/language issue. Set your editor to:

• Single expression function becomes regular when the line is greater than 180 chars AND/OR Vice-versa
• Same above, but ignore instead of breaking the line
• Other

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.

Correct point, almost. Intellij IDEA provides quick action for Kotlin SEF’s, so you may turn SEF -> Regular and vice-versa calling CTRL+ENTER, Chose correct option, Enter.
Usually, we read code tens times often then write.

Best regards,
Dmitrii Derepko.
@xepozz