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.

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 the reader may think that you are trying to replicate C# because 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.

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

This DIP allows function templates, for example

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.

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

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