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

[bauss]

On Saturday, 5 February 2022 at 16:19:42 UTC, Doigt wrote:
> On Saturday, 5 February 2022 at 14:22:07 UTC, Paul Backus wrote:
>> 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.
>
> Except commonly, and to take two popular examples: JavaScript 
> and C#, the arrow notation is not understood to be a shorthand 
> for a return expression but just an expression. I don't think 
> I'll use this new feature if I can't make my code base 
> consistent in style. It makes no sense to me to have things like
> int myFunc (int a) => something;
> void myProc (int a) { something; }
> it looks bad and it makes it seems like void is a special case 
> that is not immediately obvious why the arrow notation is not 
> used.

Yep, exactly. You'll end up with two different writing styles 
everywhere, which makes everything look inconsistent.