Feedback Thread

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

THIS IS NOT A DISCUSSION THREAD

I will be deleting posts that do not follow the Feedback Thread rules outlined at the following link:

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

The rules are also repeated below. Recently, I have avoided deleting posts that violate the rules if they still offer feedback, but I'm going to tighten things up again. Please
adhere to the feedback thread rules.

The place for freeform discussion is in the Discussion Thread at:

https://forum.dlang.org/post/jrigjbciylxzwubuopez@forum.dlang.org

You can find DIP 1043 here:

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. At that point, this thread will be considered closed and any subsequent feedback may be ignored at the DIP author's discretion.

Feedback Thread Rules

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

• All posts must be a direct reply to the DIP manager's initial post, with the following 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);
  - If the DIP author requests clarification on any specific feedback, the original commenter may reply with the extra information, and the DIP author may in turn reply as above.
• 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 (not Final Review), but 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 documentation linked above will receive much gratitude). Information irrelevant to the DIP or which is not provided in service of clarifying the feedback is unwelcome.

On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:

On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:

In the code snippet in the rationale section the line "T from, to;" is not indented properly (I assume it is not intentional). Also, I think that the rationale sample is a bit manipulative, implying that the new feature helps you save lines, however, it is omitting of the fact that for function bodies that are comprised of a single return statement you can just put the body on the same line with the definition:

```d
struct LongerExclusiveRange(T)
{
   T from, to;
   invariant(from <= to);
   bool empty() { return from == to; }
   void popFront() { ++from; }
   T front() { return from; }
}

I think that the mentioned code sample does not represent a valid argument and should be dropped from the DIP.

On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:

A simple feature, A simple DIP, simply good!

The only issue I can find is this:

Contracts are allowed with function literals, they just are not allowed with the arrow syntax. This is a good reason to keep them out of shortened functions too, but the reason stated here is inaccurate.

On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:

This round of review has concluded. Thanks to the two of you who left feedback. This thread is considered closed, though the DIP author may still respond the feedback he didn't yet acknowledge.