• Mike Parker (47/47) Jun 15 2022 This is the feedback thread for the Final Review of DIP 1043,
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (14/14) Jun 15 2022 The "brevity" section should be slashed down. Line-counting is a
• Dukc (19/21) Jun 18 2022 This DIP allows function templates, for example
• Mike Parker (3/6) Jun 30 2022 This review round has ended. Thanks to those of you who have left

Mike Parker <aldacron gmail.com> writes:

This is the feedback thread for the Final Review of DIP 1043, 
"Shortened Method Syntax".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules 
outlined in the Reviewer Guidelines (and listed at the bottom of 
this post).

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

That document also provides guidelines on contributing feedback 
to a DIP review. Please read it before posting here. If you would 
like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/drvmkookrgasjeeuuutn forum.dlang.org

==================================

You can find DIP 1043 here:

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. Feedback posted to this thread 
after that point may be ignored.

At the end of the Final Review, the DIP will be forwarded to the 
language maintainers for Formal Assessment.

==================================
Posts in this thread that do not adhere to the following rules 
will be deleted at the DIP manager's discretion:

* All posts must be a direct reply to the DIP manager's initial 
post, with only two exceptions:
      - Any commenter may reply to their own posts to retract 
feedback contained in the original post
      - The DIP author may (and is encouraged to) reply to any 
feedback solely to acknowledge the feedback with agreement or 
disagreement (preferably with supporting reasons in the latter 
case)
* Feedback must be actionable, i.e., there must be some action 
the DIP author can choose to take in response to the feedback, 
such as changing details, adding new information, or even 
retracting the proposal.
* Feedback related to the merits of the proposal rather than to 
the contents of the DIP (e.g., "I'm against this DIP.") is 
allowed in Community Review, but not in Final Review, and must be 
backed by supporting arguments (e.g., "I'm against this DIP 
because..."). The supporting arguments must be reasonable. 
Obviously frivolous arguments waste everyone's time.
* Feedback should be clear and concise, preferably listed as 
bullet points (those who take the time to do an in-depth review 
and provide feedback in the form of answers to the questions in 
the reviewer guidelines will receive much gratitude). Information 
that is irrelevant to the DIP or is not provided in service of 
clarifying the feedback is unwelcome.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

The "brevity" section should be slashed down. Line-counting is a 
very contrived argument and will only make the reader sceptical 
right from the start. The opposite of what you want to achieve.

Add more references to other languages, like Dart. As it stands 

of familiarity. You would be better off if you demonstrate that 
you have studied other languages.

Add arguments against, not only for. Like the core design 
principle of only having one way to do the same thing. Having 
multiple ways to define a method is not great for reading code of 
others. The syntax can be confusing and reduce legibility. You 
should argue for-and-against in the discourse, not only for. You 
ought to head off and tackle the criticism in the text, as the 
reader will not do it for you.

Dukc <ajieskola gmail.com> writes:

On Wednesday, 15 June 2022 at 09:21:58 UTC, Mike Parker wrote:
 This is the feedback thread for the Final Review of DIP 1043, 
 "Shortened Method Syntax".

This DIP allows function templates, for example
```D
auto sqr(T)(T x) if(isIntegral!T) => x*x;
```
. But to arrive at that conclusion, one has to check the language 
grammar spec, seeing what kind of declarations use 
`FunctionBody`. I think an explicit mention is better. Just a 
slight mention is enough IMO, no need for exploration of what 
that enables.

The examples in "brevity" curiously have five spaces added before 
the member field of the structs. It's a little unconventional. Is 
this the intention?

"but there will be fewer keystrokes by virtue of there being no 
braces": in fact it's the omission of `return` that is the 
primary character saver. Omission of braces saves theoretically 
no characters ("{}" vs "=>"). In practice it usually saves one 
character because there is one operator less, so one less of the 
spaces most add between the operators.

Mike Parker <aldacron gmail.com> writes:

On Wednesday, 15 June 2022 at 09:21:58 UTC, Mike Parker wrote:

 The review period will end at 11:59 PM ET on June 29, or when I 
 make a post declaring it complete. Feedback posted to this 
 thread after that point may be ignored.

This review round has ended. Thanks to those of you who have left 
feedback.