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

[RazvanN]

On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:
> ## 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:

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.