Re: RFC: Single-Expression functions

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. > On Jun 4, 2025, at 12:23 PM, Tim Düsterhus <tim@bastelstu.be> wrote: > > 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 {}�N�` > �>=`6 C�� 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