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

[Doigt]

On Saturday, 5 February 2022 at 00:17:23 UTC, bauss wrote:
> On Friday, 4 February 2022 at 10:53:45 UTC, Mike Parker wrote:
>> ## Discussion Thread
>>
>> This is the discussion thread for the first round of Community
>> Review of DIP 1043, "Shortened Method Syntax":
>>
>> https://github.com/dlang/DIPs/blob/5a3b437f2b6be8fb23e855fc0da20f19f68edac8/DIPs/DIP1043.md
>>
>> The review period will **end at 11:59 PM ET on February 18**, 
>> or
>> when I make a post declaring it complete. Discussion in this
>> thread may continue beyond that point.
>>
>> Here in the discussion thread, you are free to discuss anything
>> and everything related to the DIP. Express your support or
>> opposition, debate alternatives, argue the merits, etc.
>>
>> However, if you have any specific feedback on how to improve 
>> the
>> proposal itself, then please post it in the Feedback Thread. 
>> The
>> Feedback Thread will be the source for the review summary that 
>> I
>> will write at the end of this review round. I will post a link 
>> to
>> that thread immediately following this post. Just be sure to 
>> read
>> and understand the Reviewer Guidelines before posting there:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> And my blog post on the difference between the Discussion and
>> Feedback threads:
>>
>> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>>
>> Please stay on topic here. I will delete posts that are 
>> completely off-topic.
>
> From the DIP itself it wasn't clear to me whether it would only 
> support expressions that returns a value or not, because to me 
> it should also support expressions that don't necessarily yield 
> a value.
>
> So both these would be valid:
>
> ```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.