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).

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.

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.

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.

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

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...