www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback Thread: DIP 1043--Shortened Method Syntax--Community Review

reply Mike Parker <aldacron gmail.com> writes:


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.


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.
Feb 04 2022
next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:



 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.


 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.
Feb 04 2022
parent max haughton <maxhaton gmail.com> writes:
On Friday, 4 February 2022 at 15:59:54 UTC, RazvanN wrote:

 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.


It still saves typing + a projects coding standard may ban having 
the body on the same line within braces.

Typing is also not the only point of this example. The proposed 
syntax reduces the example to only the moving parts, not only 
saving typing but reducing visual noise on the screen.
Feb 05 2022
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:



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


A simple feature, A simple DIP, simply good!

The only issue I can find is this:


 Function contracts are not possible with function literals, so 
 this DIP does not address the issue.


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.
Feb 09 2022
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 4 February 2022 at 10:57:17 UTC, Mike Parker wrote:


 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.



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.
Feb 18 2022