Discussion Thread: DIP 1043--Shortened Method Syntax--Community Review Round 1

[Paul Backus]

On Saturday, 5 February 2022 at 14:13:50 UTC, Doigt wrote:
> On Saturday, 5 February 2022 at 00:17:23 UTC, bauss wrote:
>> ```d
>> void foo() { ... }
>> void bar() => foo(); // This
>>
>> private int _value;
>> void baz(int value) => _value = value; // And this
>> int baz() => _value;
>> ```
>>
>> If it's supported then I'm all for this, but if not then I 
>> think it's only a half-baked implementation.
>
> I completely agree. Coming from C# where lambda notation on 
> void is allowed, it seems weird to me that it doesn't always 
> work no matter what kind of method you're using it on. If 
> anything it introduces an inconsistency in the syntax and makes 
> it very inconvenient because it also introduces style 
> inconsistency where if your code uses single line functions 
> side by side and some use the arrow notation and others don't 
> because it's not possible by an arbitrary opinion that it 
> shouldn't be possible. To me such thinking seems rooted in the 
> past.

`=> expression` is shorthand for `{ return expression; }`, and 
the type of the expression `_value = value` is `int`, not `void`, 
so you get a type mismatch. Seems pretty straightforward to me. 
If anything, adding a special case for `void` functions would 
make it less consistent and more arbitrary.

Maybe there's an argument to be made that the compiler should 
allow this kind of `return` statement in `void` functions *in 
general*, regardless of whether you use the short or long syntax. 
But that's a totally separate issue from this DIP's proposal.