Discussion Thread: DIP 1043--Shortened Method Syntax--Final Review

[max haughton]

On Tuesday, 28 June 2022 at 10:37:08 UTC, welkam wrote:
> On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:
>> This is the discussion thread for the Final Review of DIP 
>> 1043, "Shortened Method Syntax":
>>
>> https://github.com/dlang/DIPs/blob/2c2f6c33f5761236266a96bd268c62a06323a5e8/DIPs/DIP1043.md
>>
>> The review period will end at 11:59 PM ET on June 29, 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 I 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.
>
> Burn this dip with fire. There were a lot of talks about 
> readability here but from what I can tell people mean two 
> different things when they use the word readability. One is 
> easy on the eyes, pleasant to look at. The other meaning would 
> be its easy to understand what the code is just by glancing at 
> it.
>
> Proposed changes would succeed in making code less noisy and 
> easier on the eyes but it will also harm scanability of the 
> code. Programmers rely on visual patters to understand the 
> code. That's why consistent code look is so important. That's 
> why coding standards are enforced. But its not important only 
> within a project but also across ecosystem.
>
> D doesn't have AST macros not because they are not useful but 
> because each project would look like it was written in a 
> different language. Not in extreme case but I hope you got the 
> point.
>
> Go language is the way it is for valid reasons. Don't dismiss 
> them easily.

Part of the rationale for this, other than consistency, is that 
(in my eyes at least) it requires *less* pattern recognition. 
Although I gave some hand-wavey discussion of keypresses and 
typing in the DIP, the key reason for having this in my view is 
-other than syntactic unification - that it's use allows the 
declaration of a function to be reduced to only the part that 
actually does work.

Personally, the moment a program's code looks (i.e. my eyes glaze 
over) to have patterns I am fighting a losing battle. It's just 
noise to me. At the granularity of a function declaration I do 
not feel I rely on patterns - in fact, this DIP is mainly aimed 
at methods within the definitions of classes and structs: Any 
redundant syntax in this context actively hinders reading of code 
by virtue of there being limited space on one's screen.

It may also be of note that this pattern is already widespread in 
idiomatic D code in the form of shortened function literal 
expressions.

I have no response to the point about AST macros, it doesn't seem 
particularly relevant to the DIP.