www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP Draft Reviews

reply Mike Parker <aldacron gmail.com> writes:
I'm getting ready to start prepping one of the DIPs in the PR 
queue for community review. It proposes adding an `in` operator 
for arrays. I haven't gone through it in detail yet, so I invite 
anyone with time on their hands to provide feedback on the Draft 
so we can more speedily get in shape to kick off the big-league 
reviews.

https://github.com/dlang/DIPs/pull/101

While you're at it, feel free to poke around and leave some 
feedback on other drafts in the queue.
Aug 20 2018
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 20 August 2018 at 14:54:24 UTC, Mike Parker wrote:

 I'm getting ready to start prepping one of the DIPs in the PR 
 queue for community review. It proposes adding an `in` operator 
 for arrays. I haven't gone through it in detail yet, so I 
 invite anyone with time on their hands to provide feedback on 
 the Draft so we can more speedily get in shape to kick off the 
 big-league reviews.

 https://github.com/dlang/DIPs/pull/101

 While you're at it, feel free to poke around and leave some 
 feedback on other drafts in the queue.


  pull/101 was closed.  What's happening now?
Sep 05 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 06/09/2018 2:20 AM, Nicholas Wilson wrote:

 On Monday, 20 August 2018 at 14:54:24 UTC, Mike Parker wrote:

 I'm getting ready to start prepping one of the DIPs in the PR queue 
 for community review. It proposes adding an `in` operator for arrays. 
 I haven't gone through it in detail yet, so I invite anyone with time 
 on their hands to provide feedback on the Draft so we can more 
 speedily get in shape to kick off the big-league reviews.

 https://github.com/dlang/DIPs/pull/101

 While you're at it, feel free to poke around and leave some feedback 
 on other drafts in the queue.


 
   pull/101 was closed.  What's happening now?


Last time I checked, it should be me and yshui's named parameter DIP's 
next, they really need to be reviewed together though, at least initially.
Sep 05 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 5 September 2018 at 14:30:14 UTC, rikki cattermole 
wrote:


 Last time I checked, it should be me and yshui's named 
 parameter DIP's next, they really need to be reviewed together 
 though, at least initially.


I'm not at all thrilled by the idea of running two DIPs through 
the queue in concert and would prefer to avoid that circumstance.

I've already discussed this with Yuxuan and asked if he'd be 
willing work together with you on a single DIP. His response was 
that the two proposals are not mutually exclusive and that yours 
could be built on top of his.

I need to take the time to fully absorb both DIPs and then I'll 
decide how to approach it. But you'll be hearing from me as soon 
as I do.
Sep 05 2018
parent reply Manu <turkeyman gmail.com> writes:
On Wed, 5 Sep 2018 at 20:30, Mike Parker via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On Wednesday, 5 September 2018 at 14:30:14 UTC, rikki cattermole
 wrote:


 Last time I checked, it should be me and yshui's named
 parameter DIP's next, they really need to be reviewed together
 though, at least initially.


 I'm not at all thrilled by the idea of running two DIPs through
 the queue in concert and would prefer to avoid that circumstance.

 I've already discussed this with Yuxuan and asked if he'd be
 willing work together with you on a single DIP. His response was
 that the two proposals are not mutually exclusive and that yours
 could be built on top of his.

 I need to take the time to fully absorb both DIPs and then I'll
 decide how to approach it. But you'll be hearing from me as soon
 as I do.


Out of curiosity... what's going on with mine? Is there something I'm
meant to have done? It's kinda just hanging out no?
Sep 05 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 6 September 2018 at 04:51:23 UTC, Manu wrote:


 Out of curiosity... what's going on with mine? Is there 
 something I'm meant to have done? It's kinda just hanging out 
 no?


Yours is in the Post-Community review stage [1]:

"A DIP may remain in the Post-Community Round N status for a 
maximum of 180 days. Periodically, the DIP Manager will determine 
if any post-community DIP is ready to move forward to the Final 
Review stage. Only one DIP may be in this stage at any given 
time."

I've got three DIPs in the Post-Community stage right now [2]. 
DIP 1015 will move to Final Review before yours if its author is 
ready when I am, then yours will go before 1017.

I recently sent 1014 to Walter and Andrei for Formal Assessment, 
with 1013 waiting to go when it's done. I don't know when I'll 
receive their decision, so I'm slowing the pace down for now. I 
see the Post-Community round as a staging area for the end game 
and would very much prefer to have as little time as possible for 
each DIP in the Post-Final stage. That way the Final Review 
feedback doesn't get too stale before it goes to Walter & Andrei.

I intend to move 1015 into Final Review within the next couple of 
weeks if the author is ready, so it will be at least a month 
before yours moves forward. That ultimately depends on how soon 
Walter & Andrei give me a decision on 1014.

[1] 
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
[2] https://github.com/dlang/DIPs/blob/master/DIPs/README.md
Sep 05 2018
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 6 September 2018 at 05:25:11 UTC, Mike Parker wrote:

 I've got three DIPs in the Post-Community stage right now [2]. 
 DIP 1015 will move to Final Review before yours if its author 
 is ready when I am, then yours will go before 1017.


I'm a bit worried about 1017 going in to final, given the large, 
unresolved criticisms in both draft and community review rounds. 
IMO the DIP author should at least participate in the community 
review if they expect their DIP to have _any_ chance of success.
Sep 06 2018
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 6 September 2018 at 07:13:20 UTC, Nicholas Wilson 
wrote:

 IMO the DIP author should at least participate in the community 
 review if they expect their DIP to have _any_ chance of success.


I disagree. Reviews are mainly for giving feedback, not for 
deciding the fate of the DIP -that's what the formal assesment is 
for.

IMO, it's enough that the author reads the review and addresses 
the points in the DIP before the next phase. And not every point 
has to be blindly addressed, the reviewers may be just as wrong 
as the author.

The reviews are still mentioned in the DIPs so they can be 
considered in the formal assesment, addressed by the author or 
not. And of course it's always better if the author interactively 
participates at the review, but it should not be required IMO.
Sep 06 2018
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 6 September 2018 at 09:41:39 UTC, Dukc wrote:

 I disagree. Reviews are mainly for giving feedback, not for 
 deciding the fate of the DIP -that's what the formal assesment 
 is for.


For the draft review yes, but the points against the DIP were 
raised in draft and it proceeded to community review unchanged 
without any correspondence on the part of the author, except to 
state that a reason to extend the DIP to extern(C++) function 
wouldn't work.


 IMO, it's enough that the author reads the review and addresses 
 the points in the DIP before the next phase.


I  agree, but see previous point.


 And not every point has to be blindly addressed,


No, but I expect a fraction greater then zero to be addressed.


 the reviewers may be just as  wrong as the author.


Yes but the reviewers outnumber the author by a lot, and in 
aggregate are less likely to be. That's why there are multiple 
reviewers.


 The reviews are still mentioned in the DIPs so they can be 
 considered in the formal assesment, addressed by the author or 
 not. And of course it's always better if the author 
 interactively participates at the review, but it should not be 
 required IMO.


Put it this way: DIP1017 should not go to formal without change, 
as it did from draft to community (which I don't think should 
have happened without at least some acknowledgement or refutation 
of the points raised in draft).
Sep 06 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 6 September 2018 at 10:22:47 UTC, Nicholas Wilson 
wrote:


 Put it this way: DIP1017 should not go to formal without 
 change, as it did from draft to community (which I don't think 
 should have happened without at least some acknowledgement or 
 refutation of the points raised in draft).


I always ask DIP authors about unaddressed feedback before moving 
from one stage to the other, and I did so with DIP 1017 when 
moving out of Draft Review. It's entirely up to the author 
whether or not to address it and there is no requirement for DIP 
authors to respond to any feedback. I would prefer it if they 
did, especially in the Post-Community stage and later as it helps 
me with my review summaries, but 1017 is not the first DIP where 
feedback went unaddressed and I'm sure it won't be the last.
Sep 06 2018
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 6 September 2018 at 10:49:55 UTC, Mike Parker wrote:

 I always ask DIP authors about unaddressed feedback before 
 moving from one stage to the other, and I did so with DIP 1017 
 when moving out of Draft Review. It's entirely up to the author 
 whether or not to address it and there is no requirement for 
 DIP authors to respond to any feedback. I would prefer it if 
 they did, especially in the Post-Community stage and later as 
 it helps me with my review summaries, but 1017 is not the first 
 DIP where feedback went unaddressed and I'm sure it won't be 
 the last.


I can understand not requiring authors to respond to all the 
feedback, but not requiring them to respond to _any_ is just 
wasting everyone's time, since _all_ of the previous points will 
be bought up again and the next stage will be a repeat of the 
previous.
Sep 06 2018
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 6 September 2018 at 11:18:25 UTC, Nicholas Wilson 
wrote:

 I can understand not requiring authors to respond to all the 
 feedback, but not requiring them to respond to _any_ is just 
 wasting everyone's time, since _all_ of the previous points 
 will be bought up again and the next stage will be a repeat of 
 the previous.


Yeah, I agree that if nothing or almost nothing is addressed 
(even by explaining why the raised issues didn't convince) that 
should prevent the DIP from moving forward.
Sep 06 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, September 6, 2018 4:49:55 AM MDT Mike Parker via Digitalmars-d-
announce wrote:

 On Thursday, 6 September 2018 at 10:22:47 UTC, Nicholas Wilson

 wrote:

 Put it this way: DIP1017 should not go to formal without
 change, as it did from draft to community (which I don't think
 should have happened without at least some acknowledgement or
 refutation of the points raised in draft).


 I always ask DIP authors about unaddressed feedback before moving
 from one stage to the other, and I did so with DIP 1017 when
 moving out of Draft Review. It's entirely up to the author
 whether or not to address it and there is no requirement for DIP
 authors to respond to any feedback. I would prefer it if they
 did, especially in the Post-Community stage and later as it helps
 me with my review summaries, but 1017 is not the first DIP where
 feedback went unaddressed and I'm sure it won't be the last.


Of course, what further complicates things here is that the author is
Walter, and ultimately, it's Walter and Andrei who make the decision on
their own. And if Walter doesn't respond to any of the feedback or address
it in the DIP, it all comes across as if the DIP itself is just a formality.
The fact that he wrote a DIP and presented it for feedback is definitely
better than him simply implementing it, since it does give him the chance to
get feedback on the plan and improve upon it, but if he then doesn't change
anything or even respond to any of the review comments, then it makes it
seem kind of pointless that he bothered with a DIP. At that point, it just
serves as documentation of his intentions.

This is all in stark contrast to the case where someone other than Walter or
Andrei wrote the DIP, and the author doesn't bother to even respond to the
feedback let alone incorporate it, since they then at least still have to
get the DIP past Walter and Andrei, and if the DIP has not taken any of the
feedback into account, then presumably, it stands a much worse chance of
making it through. On the other hand, if the DIP comes from Walter or
Andrei, they only have the other person to convince, and that makes it at
least seem like there's a decent chance that it's just going to be
rubber-stamped when the DIP author doesn't even respond to feedback.

I think that it's great for Walter and Andrei to need to put big changes
through the DIP process just like the rest of us do, but given that they're
the only ones deciding what's accepted, it makes the whole thing rather
weird when a DIP comes from them.

- Jonathan M Davis
Sep 06 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 6 September 2018 at 17:44:28 UTC, Jonathan M Davis 
wrote:

 Of course, what further complicates things here is that the 
 author is Walter, and ultimately, it's Walter and Andrei who 
 make the decision on their own. And if Walter doesn't respond 
 to any of the feedback or address it in the DIP, it all comes 
 across as if the DIP itself is just a formality. The fact that 
 he wrote a DIP and presented it for feedback is definitely 
 better than him simply implementing it, since it does give him 
 the chance to get feedback on the plan and improve upon it, but 
 if he then doesn't change anything or even respond to any of 
 the review comments, then it makes it seem kind of pointless 
 that he bothered with a DIP. At that point, it just serves as 
 documentation of his intentions.

 This is all in stark contrast to the case where someone other 
 than Walter or Andrei wrote the DIP, and the author doesn't 
 bother to even respond to the feedback let alone incorporate 
 it, since they then at least still have to get the DIP past 
 Walter and Andrei, and if the DIP has not taken any of the 
 feedback into account, then presumably, it stands a much worse 
 chance of making it through. On the other hand, if the DIP 
 comes from Walter or Andrei, they only have the other person to 
 convince, and that makes it at least seem like there's a decent 
 chance that it's just going to be rubber-stamped when the DIP 
 author doesn't even respond to feedback.

 I think that it's great for Walter and Andrei to need to put 
 big changes through the DIP process just like the rest of us 
 do, but given that they're the only ones deciding what's 
 accepted, it makes the whole thing rather weird when a DIP 
 comes from them.

 - Jonathan M Davis


If Walter had tried to implement this w/o a DIP, that would have 
been among the first reviews received, so it is good that he's 
has done it as a DIP. But not using it for improving the design 
is almost as bad.

I view this DIP like DIP1000 but worse: at least with DIP1000 
there was clear motivation, and despite any breakage and poor 
documentation of continued changes due to unforeseen 
requirements, it solves a real problem and has bought real value. 
It could have been handled much better, but is a net positive IMO.

DIP1017 OTOH has flawed/unsubstantiated motivation, will break 
lots of code, and solves a problem that is already solved by 
GDC/LDC where the only benefit other that documentation is faster 
code and could be solved in the same way as GDC/LDC with none of 
the breakage and complications.
Any marginal benefits in speed of compiled code for DMD _only_ 
(which is not why one uses DMD) comes at the cost of:
opportunity cost of development/review and ongoing implementation 
fixes;
unknown but probably very large code breakages;
slower compile times for all three compilers;
increased complexity in the type system and for new users;
and all the other reasons listed in the draft and community 
review.
IMO, a very much net negative

I now understand why Mihails left over DIP1000...
Sep 06 2018
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 5 September 2018 at 14:20:38 UTC, Nicholas Wilson 
wrote:


  pull/101 was closed.  What's happening now?


I'm not going to start another Community Review until I get some 
space in the latter end of the queue. But soon I'll be asking for 
Draft Review feedback on the next candidate. Right now that's 
likely to be 'Named arguments lite', but it be Rikki's.

https://github.com/dlang/DIPs/pull/123
Sep 05 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 6 September 2018 at 03:19:33 UTC, Mike Parker wrote:

 I'm not going to start another Community Review until I get 
 some space in the latter end of the queue. But soon I'll be 
 asking for Draft Review feedback on the next candidate. Right 
 now that's likely to be 'Named arguments lite', but it be 
 Rikki's.

 https://github.com/dlang/DIPs/pull/123


Did you a word? Anyway good to know that things are still moving 
forward.
Sep 06 2018