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 <t...@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 `{}` 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
